Fixes "0B of data used" in "Data Usage" summary highlight
in Settings if Telephony is not present or turned off.
Reported-By: L.W Reek <syphyr@gmail.com>
Refactored-By: Michael W <baddaemon87@gmail.com>
Signed-off-by: Vasyl Gello <vasek.gello@gmail.com>

Change-Id: I9623054c2e6e70060e65e93b18a11e8fb281d5d7

The path-permission element offers prefix or regex style matching of
paths, but most providers internally use UriMatcher to decide what
to do with an incoming Uri.

This causes trouble because UriMatcher uses Uri.getPathSegments(),
which quietly ignores "empty" paths.  Consider this example:

    <path-permission android:pathPrefix="/private" ... />

    uriMatcher.addURI("com.example", "/private", CODE_PRIVATE);

    content://com.example//private

The Uri above will pass the security check, since it's not
technically a prefix match.  But the UriMatcher will then match it
as CODE_PRIVATE, since it ignores the "//" zero-length path.

Since we can't safely change the behavior of either path-permission
or UriMatcher, we're left with recovering these shady paths by
trimming away zero-length paths.

Bug: 112555574
Test: cts-tradefed run cts -m CtsAppSecurityHostTestCases -t android.appsecurity.cts.AppSecurityTests
Change-Id: Ibadbfa4fc904ec54780c8102958735b03293fb9a
(cherry picked from commit a1ec7b11)

System content providers like SettingsProvider run as singleUser but
on receipt of a call make decisions based on the calling user ID.

This is right up until the caller is a system service or a cross-user-
-aware app like Settings, where putStringForUser etc. provide a
workaround for most settings but not for the few files SettingsProvider
exposes.

Change-Id: I90060c9c13e274edd71f8a16ab3a026a58b98e3e

SUPL_ES=1 ensures the GnssLocationProvider and related framework code
accepts incoming SMS SUPL_INIT messages with ES-bit=1
(which allow redirection of the ESLP
end-point e.g. to the current local emergency services provider when
you are travelling) only during an emergency call

Bug: 115331218
Bug: 112159033
Test: Build pass
Change-Id: I5075f7887a184ce18bb1815b35a2ce7acd8bca10
(cherry picked from commit 02f38c72)

Change-Id: I684ba2fe939ab5c2c5fc43a7047b1b76aa2db332

Remove url for AndroidVox.js

Make sure the number of entries written by Parcel#writeMapInternal
matches the size written. If a mismatch were allowed, an exploitable
scenario could occur where the data read from the Parcel would not
match the data written.

Fixes: 112859604
Test: cts-tradefed run cts -m CtsOsTestCases -t android.os.cts.ParcelTest

Change-Id: I325d08a8b66b6e80fe76501359c41b6656848607
Merged-In: I325d08a8b66b6e80fe76501359c41b6656848607
(cherry picked from commit 057a01d1)

1: Cherry-pick ag/4067454 - Setting PRIVATE_FLAG_HIDE_NON_SYSTEM_OVERLAY_WINDOWS
updateNonSystemOverlayWindowsVisibilityIfNeeded on relayoutWindow

2: Cherry-pick ag/3650369 - If PRIVATE_FLAG_HIDE_NON_SYSTEM_OVERLAY_WINDOWS changed on
relayoutWindow() then updateNonSystemOverlayWindowsVisibilityIfNeeded

3: Add permissions to SystemUI to allow it to hide non-system overlays

Bug: 34170870
Test: manual (see bug for poc)
Change-Id: I57cb0f390d9a78e721c5ddce49a377d385002753
(cherry picked from commit 40f7b583)

The crash was introduced by Ib66ef392c19c937718e7101f6d48fac3abe51ad0
The root cause of the crashing is requesting out-of-line access for the
horizontal width. This invalid access is silently ignored by
TextLine#measure() method but new implementation end up with out of
bounds access.

To makes behavior as old implementation, calling getHorizontal instead
of accessing measured result array.

Bug: 78464361, 111580019
Test: Manually done
Change-Id: I5c5778718f6b397adbb1e4f2cf95e9f635f6e5c8
(cherry picked from commit 960647d582911ae7ab8b9491097898e6c313aaf1)
Merged-In: I5c5778718f6b397adbb1e4f2cf95e9f635f6e5c8
(cherry picked from commit a1076fda)

When FLAG_GRANT_PERSISTABLE_URI_PERMISSION is requested, we still
need to check permissions between the source and target packages,
instead of shortcutting past them.

The spirit of the original change is remains intact: if the caller
requested FLAG_GRANT_PERSISTABLE_URI_PERMISSION, then we avoid
returning "-1", which would prevent the grant data structure from
being allocated.

Bug: 111934948
Test: atest android.appsecurity.cts.AppSecurityTests
Change-Id: Ief0fc922aa09fc3d9bb6a126c2ff5855347cd030
Merged-In: Ief0fc922aa09fc3d9bb6a126c2ff5855347cd030
(cherry picked from commit d6a6e712)

Certain apps may already hold permissions to an underlying provider,
but they expect APIs like takePersistableUriPermission() and
getPersistedUriPermissions() to work when a permission grant was
extended with FLAG_GRANT_PERSISTABLE_URI_PERMISSION.

Test: builds, boots
Bug: 31239684
Change-Id: I4b21c57956b70133ecadb50d0d3ee339f41e2260

Layout#getOffsetForHorizontal was running in O(n^2) time, where n is the
length of the current line. The method is used when a touch event
happens on a text line, to compute the cursor offset (and the character)
where it happened. Although this is not an issue in common usecases,
where the number of characters on a line is relatively small, this can
be very inefficient as a consequence of Unicode containing 0-width
(invisible) characters. Specifically, there are characters defining the
text direction (LTR or RTL), which cause our algorithm to touch the
worst case quadratic runtime. For example, a person is able to send a
message containing a few visible characters, and also a lot of these
direction changing invisible ones. When the receiver touches the message
(causing the Layout#getOffsetForHorizontal method to be called), the
receiver's application would become not responsive.

This CL optimizes the method to run in O(n) worst case. This is achieved
by computing the measurements of all line prefixes at first, which can
be done in a single pass. Then, all the prefix measurement queries will
be answered in O(1), rather than O(n) as it was happening before.

Bug: 79215201
Test: manual testing
Change-Id: Ib66ef392c19c937718e7101f6d48fac3abe51ad0
Merged-In: Ib66ef392c19c937718e7101f6d48fac3abe51ad0

Bug: 26524617
Change-Id: I41c0f92381bec8ad06db73b25ec67466f368b55c

Developers often accept selection clauses from untrusted code, and
SQLiteQueryBuilder already supports a "strict" mode to help catch
SQL injection attacks.  This change extends the builder to support
update() and delete() calls, so that we can help secure those
selection clauses too.

Bug: 111085900
Test: atest packages/providers/DownloadProvider/tests/
Test: atest cts/tests/app/src/android/app/cts/DownloadManagerTest.java
Test: atest cts/tests/tests/database/src/android/database/sqlite/cts/SQLiteQueryBuilderTest.java
Change-Id: Ib4fc8400f184755ee7e971ab5f2095186341730c
Merged-In: Ib4fc8400f184755ee7e971ab5f2095186341730c
(cherry picked from commit 50699426)

SQLiteQueryBuilder has a setStrict() mode which can be used to
detect SQL attacks from untrusted sources, which it does by running
each query twice: once with an extra set of parentheses, and if that
succeeds, it runs the original query verbatim.

This sadly doesn't catch inputs of the type "1=1) OR (1=1", which
creates valid statements for both tests above, but the final executed
query ends up leaking data due to SQLite operator precedence.

Instead, we need to continue compiling both variants, but we need
to execute the query with the additional parentheses to ensure
data won't be leaked.

Test: atest cts/tests/tests/database/src/android/database/sqlite/cts/SQLiteQueryBuilderTest.java
Bug: 111085900
Change-Id: I6e8746fa48f9de13adae37d2990de11c9c585381
Merged-In: I6e8746fa48f9de13adae37d2990de11c9c585381
(cherry picked from commit 57b04a86)

Change-Id: Ie387b1de461949f51185c9616dbf8349de119b23

Test: cts-tradefed run cts -m CtsShortcutManagerTestCases -t android.content.pm.cts.shortcutmanager.ShortcutManagerFakingPublisherTest
Bug: 109824443

Change-Id: I90443973aaef157d357b98b739572866125b2bbc
Merged-In: I78948446a63b428ae750464194558fd44a658493
(cherry picked from commit 9e21579a)

Bug: 77600398
Change-Id: Ia316f1c5dc4879f6851fdb78fe8b9039579be7bc
(cherry picked from commit 0d2dc943)

Bug: 77599679
Test: Compile only
Change-Id: Ib417a5cb4d51744442d2fb14437cabbe5fd1c266
(cherry picked from commit abe5a73a)

This reverts commit 53338876.

Change-Id: I5f8317ad5124e4e7c5ca2a305ddbcacb5cb177ed

* limit the absolute maximum size of the label to 50000 characters
[which is probably far more than necessary, but, can be dialed down]

* use a string buffer while processing the string [instead of creating
multiple string objects]

Bug: 62537081
Test: Manual. Install APK in bug and see that it can be uninstalled
Change-Id: Ibf63c2691ad7438a123e92110d95b1f50050f8b1
Merged-In: Ibf63c2691ad7438a123e92110d95b1f50050f8b1
(cherry picked from commit 2263da95)

Change-Id: I3964fbf3032c249db0f3c21f966d642440c1c4b5