so that it can be used by DownloadProvider as well.
Also, override getColumnNames() as well since this is
what is effectively used for getting the column count.
Bug: 111890351
Test: atest MediaProviderTests
Test: atest cts/tests/tests/provider/src/android/provider/cts/MediaStore*
Change-Id: I336729c321614d923a31521379896ce1b88ad6b0
- Create a check file for each database in order to detect
1) an unexpected DB file removal
2) DB wipe caused by a DB corruption.
- Either case, do a WTF to collect information on APR.
- Also print file timestamps in "dumpsys dbinfo". Example:
=====================
Database files in /data/system:
locksettings.db 20480b ctime=2018-10-23T22:48:35Z mtime=2018-10-23T22:48:35Z atime=2018-10-23T18:54:12Z
locksettings.db-wipecheck 0b ctime=2018-10-23T18:54:12Z mtime=2018-10-23T18:54:12Z atime=2018-10-23T18:54:12Z
notification_log.db 45056b ctime=2018-10-23T22:48:08Z mtime=2018-10-23T22:48:08Z atime=2018-10-23T18:54:13Z
:
=====================
Change-Id: I77fbeb0bb635c787aba797412f116475fecbe41c
Fixes: 117886381
Test: manual test
Test 1: corruption
1. Stop CP2 process (adb shell killall android.process.acore)
2. shell 'echo abc > /data/user/0/com.android.providers.contacts/databases/contacts2.db'
3. Launch the contacts app.
Test 2: Unexpected file removal
1. Stop CP2 process (adb shell killall android.process.acore)
2. shell 'rm -f /data/user/0/com.android.providers.contacts/databases/contacts2.db'
3. Launch the contacts app.
In both cases, logcat shows a client side stacktrace and also a WTF. (am_wtf)
*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)
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
Change-Id: I719b5c94e5b1f4fa562dd5d655953422958ad37e
Update MediaStore APIs that are effectively no-ops, including
MiniThumbFile which is no longer used.
Add support for "greylisted" columns to SQLiteQueryBuilder, so that
we can support abusive columns that match specific regex patterns
while in "strict" mode, such as COUNT(*).
Bug: 111268862
Test: atest MediaProviderTests
Test: atest cts/tests/tests/provider/src/android/provider/cts/MediaStore*
Change-Id: I364ef5bfa338ef8492b0b29c2a5c13c4189467ee
We created this API to make it easy to pass a given UserHandle into
all Managers obtained from a given Context, which works great for
"normal" users, but we should also support special users like ALL
and CURRENT.
Also add an AutoCloseable marker to make try-with-resources easier.
Bug: 112153259
Test: atest android.content.cts.ContextTest
Change-Id: I261dfcc5cfdfc76bda5d70181785e11c2715a558
*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
Change-Id: I2b193603e5dfa493ccccb8123db592f0e9c0e7ae
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.
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
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
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
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
