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
Always process class 0 and other unstored SMS (eg, MWI). We were
rejecting all SMS messages in storage full situations, but certain
messages do not require storage.
Also, notify apps when the framework rejects MT SMS, with new
SMS_REJECTED_ACTION intent.
b/2066775
b/2015906
This is necessary partly for general hygiene, but mostly because we need
to be able to determine based on the intent type what style URI to
return in the case of startActivityForResult().
Change-Id: Ib313d830b8646a70d5ac3ded11597af614429262
The main consumer of this feature is shortcuts.
The LOOKUP KEY column will contain an encoded concatenation of the contact's row id
as well as sync_ids of all constituent raw contacts. It goes with the "contacts/lookup/*/#" URI.
When we get such a URI, we will first try to load the
contact with the specified _id and lookup_key. If we cannot find the contact
that way, we will go scout for the contact that contains most of the sync_ids
we found in the lookup key.
We will need to make sure that the contact picker returns the lookup-style URIs.
Now that we've merged ContactsContract and are relying on
compatibility mode, we're marking the previous public
contacts API as deprecated.
Fixes http://b/2076016
When we select this option, this sequence of characters (which is neither a
valid email address nor a phone number), gets stored in contact with type MOBILE.
Fix: In function canAddToContacts, adding a check to validate whether the contact
to be added is a valid email address or phone number. If not, user will not be shown
with the option "Add to Contacts".
Also added ContactHeaderWidget accessor for passing along
this list when triggering Fast-Track. This is used so that
the header widget can hide the profile icon when launched
while already looking at the profile.
