Add new API which clients can use to force an SDP query.
The result is broadcast using an intent having the UUIDs.
The intent is broadcast after a timeout, in case of an error.
This timeout is greater than the page timeout.
Change-Id: I61e6db4c05b34c42f679a66987e37e2063a793b6
* changes:
Unhide attributes textAppearanceSearchResultSubtitle and attr/textAppearanceSearchResultTitle. We had discussed doing this in Donut but looks like it never happened. We need these attributes for voice search so now's as good a time as any.
attr/textAppearanceSearchResultTitle. We had discussed doing
this in Donut but looks like it never happened. We need these
attributes for voice search so now's as good a time as any.
The rationale is this. Since all these joined columns are currently on
different classes, we routinely see code like this:
private static final String[] PROJECTION_PHONE = {
Data._ID, // 0
Data.CONTACT_ID, // 1
Phone.TYPE, // 2
Phone.NUMBER, // 3
Phone.LABEL, // 4
Data.DISPLAY_NAME, // 5
};
After this change, the above declaration changes to:
private static final String[] PROJECTION_PHONE = {
Phone._ID, // 0
Phone.CONTACT_ID, // 1
Phone.TYPE, // 2
Phone.NUMBER, // 3
Phone.LABEL, // 4
Phone.DISPLAY_NAME, // 5
};
Change-Id: I2e84bca3277aeef06eec20cee8c2119ef3b90a9f
In particular, this no longer attempts to back up the on/off state of specific
backend syncing [gmail/contacts/calendar], nor the "background data" toggle.
The former was causing a great deal of spurious trips through backup as the
notification was being tickled during general sync operation, and the latter
makes little sense at restore time.
Fixes these issues:
b/2097613 - frequent "backup_data_changed" messages in event log
b/2131662 - should not backup background data, master sync settings
The rationale is this. Since all these joined columns are currently on
different classes, we routinely see code like this:
private static final String[] PROJECTION_PHONE = {
Data._ID, // 0
RawContacts.CONTACT_ID, // 1
Phone.TYPE, // 2
Phone.NUMBER, // 3
Phone.LABEL, // 4
Contacts.DISPLAY_NAME, // 5
};
The most noxious line is RawContacts.CONTACT_ID
After this change, the above declaration changes to:
private static final String[] PROJECTION_PHONE = {
Data._ID, // 0
Data.CONTACT_ID, // 1
Phone.TYPE, // 2
Phone.NUMBER, // 3
Phone.LABEL, // 4
Data.DISPLAY_NAME, // 5
};
Change-Id: I03bfc700e4c8c58a175bc885bf7b807d7fed0744
When parsing an SMS message as email, extractEmailAddressFromMessageBody()
checks parts.length >= 1, but then proceeds to access parts[1] (which
may not exist). Instead, check for parts.length >= 2, and treat
parts.length = 1 as non-email.
b/2122698
The rationale is this. Since all these joined columns are currently on
different classes, we routinely see code like this:
private static final String[] PROJECTION_PHONE = {
Data._ID, // 0
RawContacts.CONTACT_ID, // 1
Phone.TYPE, // 2
Phone.NUMBER, // 3
Phone.LABEL, // 4
Contacts.DISPLAY_NAME, // 5
};
The most noxious line is RawContacts.CONTACT_ID
After this change, the above declaration changes to:
private static final String[] PROJECTION_PHONE = {
Data._ID, // 0
Data.CONTACT_ID, // 1
Phone.TYPE, // 2
Phone.NUMBER, // 3
Phone.LABEL, // 4
Data.DISPLAY_NAME, // 5
};
Change-Id: I820e68efd6c1364241596f826c4da1b9c2defe11
The density test expects all resources of all densities to be included, but specifying a density for a particular device build kills that. We therefore add all the required densities explicitly to the Makefile to compensate.
This keeps consistency with Bluez which uses upper case string address. It's
important to keep the case the same so that .equals() in BluetoothService.java
work.
Change-Id: I6404ca137d0aec3cc2e6e7cb79763d5305a03547
Resolves these specific cases:
- 8475766800;,1234
- 8475766800,;1234
Both of these should be converted to 8475766800;1234
Change-Id: Ic329007a3a6e99b1dd55cd8cdec7239dd734c3ca
This is to help collect information from Moto QA about delays connecting BT
audio.
Change-Id: I790c65f5b64c85aaffc0e68ebe8b6202f476b39f
http://b/2129464
