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
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
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
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: 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)
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
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)
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
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
If set, Compatibility WAL will not be used.
Currently this flag is set if SQLiteOpenHelper.setWriteAheadLogging(false)
is called before opening the database. Previously this call was ignored
since ENABLE_WRITE_AHEAD_LOGGING flag is only set when setWriteAheadLogging(true)
Test: CtsDatabaseTestCases
Bug: 74116447
Change-Id: Ic486e178b9da5d747840be739303a2685b91f35b
Using the new constructor can be difficult as it requires an app to
make a decision which version of constructor to use before instantiating
the object. By adding setOpenParams method, apps can keep the old
structure of the code and only add API level check after instantiating
a helper object.
Test: SQLiteOpenHelperTest
Bug: 70863722
Change-Id: I1705dd790e3549d0d8e75eb33b1d9b5bdadcb3c9
Add @GuardedBy for simple functions that require a single lock
and are named XYZLocked.
Bug: 73000847
Test: m
Test: m javac-check-framework RUN_ERROR_PRONE=true
Change-Id: Icb5114fea2ff2385e1cc7511121026099e05c0ee
The majority of Manager-style classes already use Context.getUserId()
when making calls into the OS, so clean up the remaining callers to
unify behind this strategy.
This gives @SystemApi developers a nice clean interface to interact
across user boundaries, instead of manually adding "AsUser" or
"ForUser" method variants, which would quickly become unsustainable.
Test: builds, boots
Bug: 72863821
Exempt-From-Owner-Approval: trivial changes
Change-Id: Ib772ec4438e57a2ad4950821b9432f9842998451
In system_server, it should be deactivated until InstallSystemProviders
is finished.
Test: SQLiteCompatibilityWalFlagsTest
Test: setting put global ... + verify that dumpsys dbinfo has the new flag
Bug: 70226732
Bug: 70517616
Change-Id: Iec6a5e61a5d7e4cc0ac602f2b630357c54bb4456
Added Settings.Global.SQLITE_COMPATIBILITY_WAL_FLAGS -
configuration flags for SQLite Compatibility WAL. Encoded as a key-value
list, separated by commas. E.g.:
compatibility_wal_supported=true, wal_syncmode=OFF
SQLiteCompatibilityWalFlags caches the value of
SQLITE_COMPATIBILITY_WAL_FLAGS on first access and keeps it through
the lifetime of the process for consistent behavior across all
connections.
Test: SQLiteCompatibilityWalFlagsTest
Test: setting put global ... + verify that dumpsys dbinfo has the new flag
Bug: 70226732
Bug: 70517616
Change-Id: Ifacbf5908c83351ebe5dea676eeb716af039fb14
If DDL statement is executed on one connection, the schema change is
not always visible to other connections due to sqlite3_column_count()
API limitation. We have to close secondary connections to prevent the
issue.
Test: cts/SQLiteOpenHelperTest
Bug: 33695159
Change-Id: I862da71ecec5b1edc880dbfadf22efb2274ca10a
The android.database.sqlite package summary page now mentions the
versions of SQLite that are available on Android devices running Oreo
(API level 26) and API level 27.
Test: make ds-docs -j16
Bug: 69106585
Change-Id: I77a323c58343fa978ade5397d613566ba25f00c2
Added setJournalMode/setSynchronousMode. These methods control
journal/syncrhonous mode when ENABLE_WRITE_AHEAD_LOGGING flag is not set
Bug: 33044236
Test: manual + CtsDatabaseTestCases
Change-Id: Iffef75f6941030aae5ab3e239cd65550515f5fe0
In this mode, only database journal mode will be changed, connection pool
size will still be limited to a single connection.
If enabled, compatibility WAL mode will be used if an app hasn't explicitly
requested journal mode, by calling disable/enableWriteAheadLogging.
Compatibility WAL mode is controlled by debug.sqlite.use_compatibility_wal
property and db_use_compatibility_wal config resource.
Impact on write performance:
On ext4, with WAL, there is approx 300% increase in speed of update operations
On f2fs, with WAL, there is approx 5% increase in speed of update operations
Impact on number of writes:
On ext4, switching to WAL reduces the number of writes by approx 50%.
On f2fs, switching to WAL increases the number of writes by approx 15%.
Test: CtsDatabaseTestCases
Test: manual, running device
Bug: 33044236
Change-Id: Iaffb5651df39d8c9f710d7dbbe174f9c0d8a3186
