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: I2bcc7f0eee31a1775dd7a5dd0f291d0d37bc1292
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
For new storage changes in Q, we need to redact the visibility of
the "_data" column on any returned cursors. We could cook this up
using SQLiteQueryBuilder projection re-mappings, but that's a pretty
involved change due to the number of tables and teasing apart
public-vs-hidden API columns.
Instead, this RedactingCursor class offers to "redact" requested
columns by replacing with specific values, such as "/dev/null".
Test: atest frameworks/base/core/tests/coretests/src/android/database/RedactingCursorTest.java
Bug: 111960973
Change-Id: Iad36986fc0b7a0cae10ff216755e284320991e18
- Show DB filename
- Print result for execute-for-string and for-long to debug PRAGMA
related issues.
Bug: 112175067
Test: booted with "setprop db.log.slow_query_threshold 0" and
"setprop db.log.detailed 1"
Change-Id: I2a4093755b3fe7a6ae2c0fad93f8224da834062e
Keeps existing public APIs intact, but rewrite the internal to pave
the way for storage changes coming in Q. All thumbnail generation
and reading now happens in MediaProvider, since apps won't have
direct access to MiniThumbFile files in Q.
Instead, InternalThumbnails now uses openTypedAssetFileDescriptor()
to open the original Uri, but with an EXTRA_SIZE indicating that
it'd like a thumbnail of a specific size. This uses best-practices
which allow apps obtaining a Uri permission grant to a specific
media Uri to request a thumbnail of that media without additional
permissions. This also lets us use CancellationSignal to cancel
thumbnail requests that are no longer needed, and we start checking
this signal at each query() point internally.
Move internals to use ExecutorService pattern, which will let us
expand the thread pool in a future CL based on device capabilities.
Previous logic that asynchronously generated thumbnails after certain
actions is now replaced with simpler invalidation. This paves the
way for us to move proactive thumbnail generation to be driven by an
idle maintenance service, to be better stewards of battery life. We
continue to generate thumbnails on-demand when not yet cached.
ThumbnailUtils already handles extracting EXIF thumbnails, so we don't
need to duplicate that work locally.
Flag that enables dumping of all raw SQL for debugging purposes on
a per-process basis.
Bug: 111268862, 111890672
Test: atest cts/tests/tests/provider/src/android/provider/cts/MediaStore*
Change-Id: Ibcdbc564c8fee09ddd33ebccc470fa5cbdff97b4
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
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
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
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
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
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
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
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
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
Change-Id: I60b6f69045766bb28d2f21a32c120ec8c383b917
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
