GitLab

- If an app (not SYSTEM or PHONE) tries to set CREATOR column when
inserting a message, it will be silently overridden by the true pacakge
name of the caller. Or if it tries to update the column, it will be
sliently dropped.
- Also fixed some PII issues

b/18393308

Change-Id: I4ac739b9a6cb78797f006f17c0eed3eeb64cc65e

b/17542798

Change-Id: I21c8546fdc692dcdbf6a1208dc73284b2e3951e2

Potential fix for secondary users not getting content observer
callbacks for sms updates.

Bug: 16681533
Change-Id: I80353680f5da52ca5a23cde7804e9eaab9516f9a

So we don't need to hard code the check anymore. Revert back to use
AppOps for write permission check as we did in KitKat.

Change-Id: If3a2a7a3a3b53864f73e6023fdd0649d3c2e61c3

b/14095333

Change-Id: I77d33a177fadba482c1571b59a10d6ebf1863a43

New SMS and MMS database columns: archived and creator

b/14095333

Change-Id: I4d79014c12ac622b098c1b7892134ce842f70f83

Changed permission control for new SMS APIs. Only phone and system UID
are allowed.

b/14095333

Change-Id: I140c0a895b07f72a7840927a1008ea8f7dce8d46

b/15673719

Change-Id: I0f3d6c3bfaead109edef283ac45d7e5f8c3220b4

Sending a quick SMS reply to an incoming phone call was failing
with a SecurityException due to new AppOps code. The root cause
was the insert() call in SmsProvider was calling back into itself
using the UID of the caller (com.android.mms) but the package name
for the callee (com.android.phone).

Wrapped the insert() method of SmsProvider with a helper function
to save the Binder identity and restore it on completion. This
allows the quick response to make its own provider queries using
its own UID as well as package name. Read/write security checks
will be performed by the content provider framework based on the
manifest file, before insert() is called.

Bug: 11006277
Change-Id: I4c0c8041a2505c5aad8db9b2dbab5402728f9221

When accessing SMS stored on UICC via TelephonyProvider, we need to
use the com.android.phone UID for the call to IccSmsInterfaceManager
to avoid a UID mismatch failure in the app ops check. Add code to
SmsProvider to save and restore the original caller identity.
Also set android:multiprocess attribute to false in the manifest so
that the providers don't run inside the caller's process, which
also leads to a security exception.

Bug: 10131077
Change-Id: Ie6d3477b14973632f3706201de91353950359ee0

Change-Id: I17b5154c2eb53cbde9d562fb23a9ce047fe41327

Bug 6453254

Don't allow a thread to be created with no recipients. Return null so
the situation can be dealt with by the caller.

Change-Id: Idd82ac5967524287e894ecd72b2bc01a1d3f639f

Bug 5614340
The provider needs to assign each SIM message a unique id.

Change-Id: I9329a0770423fcbb04c5906ec60453ee695fbfff

Change-Id: I2d46932c79883d2601be8531a00ba8dbfd165076

Change-Id: I2d6874943008b819c987bd5cef0f530eb2283ca3

1.  introduce an FTS3 indexed table called "words"
2.  put all sms messages into the words table (done in the SmsProvider's insert).
3.  put all part messages which are plain text into the words table (done in the MmsProvider's insert).
4.  put triggers on the delete and update for sms and part and update words appropriately.
5.  remove the search recents code (mainly commented out) within the mms app.
6.  implement a suggest provider which queries the words table for matches.
7.  modify the search activity to use the words table rather than a LIKE clause.
8.  modify the search activity to use a regular expression (rather than String.indexOf) for
    generating the snippet and highlighting the appropriate words within the snippet.  NOTE
    that originally I wanted to compute the matching words positions using the sql offsets
    function but it doesn't work within the slightly complicated query which is used for
    doing the search (two joins and a union, etc.)
9.  modify the highlighting code within compose message activity to use regular expressions
    rather than indexof to do the highlighting.
10. what else did I forget?

Several files were moved to android-common. Update all the references
to import those files from the new location.

We need a locked column for the SMS messages we read from the SIM,
otherwise the UI gets a result telling us the message is locked
when querying the cursor for the locked value.
This is part two of three fixes for BC-triaged bug 2205782.

Change-Id: I6682503fc6ec4e65fc75ca57ae4d2c34ff04f6b0

- this needs to be fixed for real by the Contacts team.

Change-Id: Ibb10ebc51c9f4b6bc63dec609ab14de0e53eea86

Change-Id: Ia898c8a09146b4635c31b5adbf8d3baa77567727

Add support for the ability to lock individual messages from getting  automatically
deleted by the recycler. A new column was added to both the sms and mms side of the
messaging world.

The recycler allows a user to turn on setting that'll limit the number
of messages saved per thread. An eventual UI will allow users to lock
messages and prevent them from being deleted. This change adds a couple
of tweaks to be able to query the number of messages per thread id, etc.

This will allow the app to stop checking if a draft exists
before deciding to either update or insert, which will save a
database roundtrip.

Automated import of CL 144245

Automated import of CL 144185