Members modified herein are suspected to be false positives: i.e. things
that were added to the greylist in P, but subsequent data analysis
suggests that they are not, in fact, used after all.
Add a maxTargetSdk=P to these APIs. This is lower-risk that simply
removing these things from the greylist, as none of out data sources are
perfect nor complete.
For APIs that are not supported yet by annotations, move them to
hiddenapi-greylist-max-p.txt instead which has the same effect.
Exempted-From-Owner-Approval: Automatic changes to the codebase
affecting only @UnsupportedAppUsage annotations, themselves added
without requiring owners approval earlier.
Bug: 115609023
Test: m
Change-Id: Ia937d8c41512e7f1b6e7f67b9104c1878b5cc3a0
Merged-In: I020a9c09672ebcae64c5357abc4993e07e744687
Everything that is marked SystemApi or TestApi, but not @hide is still
part of the public SDK, it is therefore not sound to have that combination.
In the future, specifing such a combination will be considered an error
to prevent inadvertently exposing SystemApi and TestApi as public API.
Bug: 115333477
Change-Id: Ibd5d6a22862fdbc1e20a1cb3925280f5a682edea
Merged-In: Ibd5d6a22862fdbc1e20a1cb3925280f5a682edea
Test: METALAVA_PREPEND_ARGS="--error UnhiddenSystemApi" m checkapi
Exempt-From-Owner-Approval: API cleanup
It's wasteful to convert them to String when SQLite already knows
how to bind specific data types, including funky types like byte[].
Also promote to public API, since they're generally useful.
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
Merged-In: I5b418bca1204773fd2795156a2f47906ca1e1a6b
Change-Id: I386cbc97cf3499823bc10251ff315ce381db24cc
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: Ibc8ce8b1801e7bfd946655fcf8b6865b6d71227c
Merged-In: Ib4fc8400f184755ee7e971ab5f2095186341730c
The existing appendWhere() methods aren't very friendly for
developers, since they require manual tracking of state to decide if
subsequent standalone chunks should be prefixed with "AND".
While it's tempting to offer direct argument binding on the builder
class, we can't really deliver on that API in a secure way, so instead
add separate bindSelection() method which explicitly burns arguments
into a standalone selection string, which can then be appended to
the builder.
This was the last piece of new functionality being used by
SQLiteStatementBuilder, so we can delete that class and migrate
users back to SQLiteQueryBuilder.
Bug: 111268862
Test: atest frameworks/base/core/tests/coretests/src/android/database/DatabaseUtilsTest.java
Test: atest frameworks/base/core/tests/utiltests/src/com/android/internal/util/ArrayUtilsTest.java
Test: atest cts/tests/tests/provider/src/android/provider/cts/MediaStore*
Test: atest cts/tests/tests/database/src/android/database/sqlite/cts/SQLiteQueryBuilderTest.java
Merged-In: I418f24338c90bae8a9dad473fa76329cea00a8c5
Change-Id: I418f24338c90bae8a9dad473fa76329cea00a8c5
It's wasteful to convert them to String when SQLite already knows
how to bind specific data types, including funky types like byte[].
Also promote to public API, since they're generally useful.
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
Merged-In: I5b418bca1204773fd2795156a2f47906ca1e1a6b
Change-Id: I5b418bca1204773fd2795156a2f47906ca1e1a6b
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
Merged-In: Ib4fc8400f184755ee7e971ab5f2095186341730c
Change-Id: Ib4fc8400f184755ee7e971ab5f2095186341730c
We've encountered subtle bugs in how apps are using this public
API, so revert it back to exactly what shipped in the last
release, and move functionality to new SQLiteStatementBuilder
class, since we already have several customers using it.
Test: atest cts/tests/tests/provider/src/android/provider/cts/MediaStore*
Test: atest cts/tests/tests/database/src/android/database/sqlite/cts/SQLiteQueryBuilderTest.java
Bug: 111486645
Merged-In: Ief059e987f2421e19f6f57a94320c313946a26d7
Change-Id: Ief059e987f2421e19f6f57a94320c313946a26d7
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
Merged-In: I6e8746fa48f9de13adae37d2990de11c9c585381
Change-Id: I6e8746fa48f9de13adae37d2990de11c9c585381
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
Merged-In: Ie85a95003ae134eef2fdfbf074c2f82d0a6a9f26
Change-Id: Ie85a95003ae134eef2fdfbf074c2f82d0a6a9f26
When users are building queries, they often need to append several
standalone SQL clauses, and it's tedious to track their first clause
so they can manually append " AND " to each subsequent clause.
So add new appendWherePhrase() API which appends a standalone phrase
which is AND'ed together with any existing WHERE query.
Also fix bug in update() which would turn null values into the
string literal "null" instead of passing them through as SQL NULL.
Test: atest cts/tests/tests/database/src/android/database/sqlite/cts/SQLiteQueryBuilderTest.java
Bug: 111085900
Merged-In: Ia280dd864895654239503e080eaef925f5620d37
Change-Id: Ia280dd864895654239503e080eaef925f5620d37
Despite SQLite documentation saying these clauses follow the "expr"
syntax, queries will fail with obscure "row value misused" errors,
so remove the strict enforcement for now.
Test: manual
Bug: 111480817
Merged-In: Ib8cdcb4e6456110589203189fcfa14e75cd68718
Change-Id: Ib8cdcb4e6456110589203189fcfa14e75cd68718
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.
Extend it to support selection arguments being provided when
appending appendWhere() clauses, meaning developers no longer need
to manually track their local selection arguments along with
remote arguments.
Extend it to support newer ContentProvider.query() variant that
accepts "Bundle queryArgs", and have all query() callers flow
through that common code path. (This paves the way for a future
CL that will offer to gracefully extract non-WHERE clauses that
callers have tried smashing into their selections.)
Updates ContentValues to internally use more efficient ArrayMap.
Bug: 111268862
Test: atest frameworks/base/core/tests/utiltests/src/com/android/internal/util/ArrayUtilsTest.java
Test: atest cts/tests/tests/database/src/android/database/sqlite/cts/SQLiteQueryBuilderTest.java
Merged-In: I60b6f69045766bb28d2f21a32c120ec8c383b917
Change-Id: I60b6f69045766bb28d2f21a32c120ec8c383b917
Based on some analysis, these fields/methods are likely false positives.
Set maxTargetSdk=P so that any apps using them are required to migrate off
them in future. See the bug for more details.
Exempted-From-Owner-Approval: Automatic changes to the codebase
affecting only @UnsupportedAppUsage annotations, themselves added
without requiring owners approval earlier.
Bug: 115609023
Test: m
Merged-In: I719b5c94e5b1f4fa562dd5d655953422958ad37e
Change-Id: I719b5c94e5b1f4fa562dd5d655953422958ad37e
(cherry picked from commit 8c854f86a4)
*1 -- not truncate(2) but "PRAGMA wal_checkpoint(TRUNCATE)"
Otherwise, depending on how an app operate on a DB, SQLite may not
have a chance to "shrink" the WAL file.
Fixes: 112777941
Bug: 111939259
Test: atest /android/master/frameworks/base/core/tests/coretests/src/android/database/sqlite/SQLiteCompatibilityWalFlagsTest.java
Test: Manual test with google dailer:
1. With normalized_spam.db-wal > 100MB and receive a phone call
-> WAL file gets truncated to 0 bytes.
2. Restart the dialer process and receive a phone call again
-> WAL file is already 0 bytes; won't be truncated.
3. Restart with the WAL file deleted
Same as #2. WAL file will be created before the added logic, but is 0 bytes,
so it won't be truncated.
4. Test with settings put global sqlite_compatibility_wal_flags truncate_size=1024
-> make sure the threshold is overridden
Merged-in: I2b193603e5dfa493ccccb8123db592f0e9c0e7ae
Change-Id: I2b193603e5dfa493ccccb8123db592f0e9c0e7ae
(cherry picked from commit 96e06002ed)
Test: change pin and immediately crash the kernel with
adb shell 'su root sh -c "echo c >/proc/sysrq-trigger"' and boot
Bug: 112175067
Change-Id: Ia5f43f3118e2297fbea43c805ef2f4577bf8a9bf
(cherry picked from commit 50e00c8dc4)
Merged-in: Ia5f43f3118e2297fbea43c805ef2f4577bf8a9bf
Test: change pin and immediately crash the kernel with
adb shell 'su root sh -c "echo c >/proc/sysrq-trigger"' and boot
Bug: 112175067
Change-Id: Ia5f43f3118e2297fbea43c805ef2f4577bf8a9bf
(cherry picked from commit 50e00c8dc4)
Otherwise, Metalava based android_test_current.jar doesn't contain
SQLiteDebug.class which caused build failure on:
out/target/common/obj/APPS/CtsDatabaseTestCases_intermediates/classes-full-debug.jar
Test: CtsDatabaseTestCases
Bug: 77543575
Change-Id: Ied9948e962fb7a81e56be0360cb94b0c318ad14d
Merged-In: Ied9948e962fb7a81e56be0360cb94b0c318ad14d
(cherry-picked from 6fe565e441)
Exempt-From-Owner-Approval: Cherry-picked a CL from git_master, and owner just agreed to use Exempt-From tag.
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 506994268b)
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 57b04a8680)
Bug: None
Test: I solemnly swear I tested this conflict resolution.
Merged-In: I2bcc7f0eee31a1775dd7a5dd0f291d0d37bc1292
Change-Id: I227ce12b7419ce8541a362f98adc50965b779c3b
For packages:
android.database.sqlite
android.database
This is an automatically generated CL. See go/UnsupportedAppUsage
for more details.
Exempted-From-Owner-Approval: Mechanical changes to the codebase
which have been approved by Android API council and announced on
android-eng@
Bug: 110868826
Test: m
Change-Id: I0da613d00611e89e49bf73c9ffe35700818efc6b
Merged-In: I2bcc7f0eee31a1775dd7a5dd0f291d0d37bc1292
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
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
setSynchronousMode is now applicable to any journal mode.
This can be useful for apps that want to use stricter durability
settings for their database.
Test: android.database.sqlite.cts.SQLiteDatabaseTest
Bug: 86953240
Change-Id: I7dbaa6d0bc0975da8067e87b402f63f51b4add10
