We recently added several new phone types, and this change
updates the API that resolves thoses types to strings. It
also uses unique string resources for each type, instead of
relying on types to be <string-array> indexes.
Fixes http://b/2118886
This is a minor optimization for the sake of the aggregator. The aggregator now relies on the display name
instead of structured components. As a result, we only need one column from the data table
for the structured name. For other data types it's data1. Might as well use the same column
for display name.
Change-Id: Ib22d1f1a7a91f12716d1a460e1578f01926c393a
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
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
Change internal widget to use new FastTrack API instead of
using SHOW_OR_CREATE. Also reset the internal Uri when
reused in lists. Fixes http://b/2087222
I added a new API to help us move away from launching
FastTrack through SHOW_OR_CREATE. For now it's going to
still pass through as an Intent with extras, but in the
future this could be used to launch a Window from a system
service.
Partially fixes http://b/2087222
Add changes to have the ability to turn on and off the
automatic light sensing for the device. This is fully configurable
and is by default not present. Vendors should override the ALS setting
to enable the automatic lighting controls.
These changes will add a check box to the Brightness settings menu to give control
to the user to allow the device's display lighting to be controlled via the slide bar
or the auto lighting system.
If the user selects auto then the slide bar will become invisible. Manual mode
will present the slide bar to the user.
Change-Id: I146a6d75b99b08c9b839218ce6b85adf21f9fd73
Signed-off-by: Dan Murphy <D.Murphy@motorola.com>
Signed-off-by: Mike Lockwood <lockwood@android.com>
* Remove several nonportable telephony settings from the set to be included in
the backed-up dataset
* Explicitly ignore those settings if they're encountered during a restore
operation, so that we don't inadvertently do things like configure a GSM
phone to use CDMA logic.
Also, introducing a more advanced email filter, which will do a proper name
lookup using the normalized name and avoid returning duplicate results.
Also, upgrading the phone filter to do the same thing as the email filter
but with display names and phone numbers.
The current API requires a contact_id and a raw_contact_id
There are at least two issues with this approach I did not recognize initially:
1. Contact_id may be changed asynchronously by aggregation or some other process.
2. A raw contacts may need to be added to an aggregate before the actual aggregation pass
has gotten to it, so the client would need to wait for the aggregation to complete
before it can set an aggregation exception. That's backwards.
we keep book and only read a particular file once and send it to the server.
The files are:
Ramconsole Driver (Dream/Sapphire):
/data/dontpanic/last_kmsg
Apanic Driver (Sholes/all future designs):
/data/dontpanic/apanic_console
/data/dontpanic/apanic_threads
