Exposing CursorWindowAllocationException to access it
from Bluetooth PBAP.
Tag: #feature
Bug: 211851706
Test: manual
Change-Id: I9a2c4217e5556f7b8ab10c3884a0d3e9b6a4fe36
Unless we are looking at stack traces (e.g. from strict mode) it's not
possible to identify which type of object is not being closed (most
methods are 'close' or 'release). Change the logged text to clarify.
Change-Id: Ib90eac716f43c2c2caf8d8c6fb64a7bd90562da9
Test: manual
This fixes dumpsys dbinfo not reporting the journalMode and syncMode as
well and made flags and configuration converge to the same value which
is less bug prone.
Test: dumpsys dbinfo
Bug: 193925357
Change-Id: I9a30b64b06a94fa9bd5589eba391a561ddcfaaf0
Also add ContentObserver#onChange(boolean, Collection, int, UserHandle) so
clients can know the corresponding UserHandle for the notification.
Bug: 203606981
Test: atest CtsContentTestCases and manual testing to verify the observer can get notifications for
all the users.
Change-Id: Icec7e70b71d7de1c15faf1736539f169856304a8
This fixes an issue where execPerConnectionSQL() would fail with certain
PRAGMA statements that both set a value and return a result, such as
busy_timeout, max_page_count, etc.
Bug: 197128690
Test: atest CtsDatabaseTestCases
Change-Id: I1904ccfd6795c38ce55800bdd074ffba083638af
Log.isLoggable is expensive for frequent operations. Replace with a
pre-determined check.
Bug 188428246
Test: Built
Change-Id: I77f1980c289b44c8dafd4113771fd814ff382a83
The android.database.sqlite package summary page now mentions the
versions of SQLite that are available on Android devices running Pie
(API level 28), Q (API level 29), R (API level 30) and S (API level 31)
Change-Id: I49c6bdd7edbaf98a62f50cb65ba00f160c800f0c
Test: make ds-docs -j16
This reverts commit 0ace970e19.
Bug: 174932174, 175111824
Exempt-From-Owner-Approval: refactoring with team leads buy-in
Change-Id: I152186408ecf6da1cb7354d14737de7cce55a34b
We're temporarily blocked on internal Gerrit tooling to support
relaxed OWNERS validation, so this change temporarily replaces all
"android.com" accounts with "google.com" equivalents.
Bug: 174932174,175111824
Exempt-From-Owner-Approval: refactoring with team leads buy-in
Change-Id: I114f2a40cee1b65e21250da7372e11c18cd73e25
Protect Cursors with CloseGuard and report implicit cleanup.
By default, the leak detection code will print a one-line warning
message about failing to call the cleanup function. To report more
details like the original stacktrace and SQLite query statement, enable
the correspoinding VmPolicy flags as the example below, please.
/*
* public void onCreate() {
* if (DEVELOPER_MODE) {
* StrictMode.setVmPolicy(new VmPolicy.Builder()
* .detectLeakedSqlLiteObjects() // for SqlLiteCursor
* .detectLeakedClosableObjects() // for any Cursor
* .penaltyLog()
* .build());
* }
* super.onCreate();
* }
*/
By enabling detectLeakedSqlLiteObjecs, the original SQLiteCursor query
statement is reported when close() or its equivalent cleanup function
is not called before finalize().
By enabling detectLeakedClosableObjects, the new CloseGuard report will
be provided, along with the original stack trace captured in open() or
its equivalent.
The former has better performance as it doesn't capture an original
stack trace during open() stage. Only enable the latter if performance
impact is not an issue. Both of them can be enabled at the same time.
Bug: 168639120
Test: manually test with an example SQLite Android application, with and
without calling cursor.close() after a db.rawQuery().
Change-Id: Ibe9fcdc8119c2e4651df1983e7ccd793f29e8e9d
Signed-off-by: Li Li <dualli@google.com>
These are APIs that have @UnsupportedAppUsage but for which we don't
have any evidence of them currently being used, so should be safe to
remove from the unsupported list.
Bug: 170729553
Test: Treehugger
Merged-In: I626caf7c1fe46c5ab1f39c2895b42a34319f771a
Change-Id: I54e5ecd11e76ca1de3c5893e3a98b0108e735413
These are APIs that have @UnsupportedAppUsage but for which we don't
have any evidence of them currently being used, so should be safe to
remove from the unsupported list.
This is a resubmit of ag/12929664 with some APIs excluded that caused
test failures; see bugs 171886397, 171888296, 171864568.
APIs excluded:
Landroid/bluetooth/le/ScanRecord;->parseFromBytes([B)Landroid/bluetooth/le/ScanRecord;
Landroid/os/Process;->myPpid()I
Landroid/os/SharedMemory;->getFd()I
Landroid/hardware/input/InputManager;->INJECT_INPUT_EVENT_MODE_WAIT_FOR_FINISH:I
Bug: 170729553
Test: Treehugger
Change-Id: I8285daa8530260251ecad6f3f38f98e263629ca7
These are APIs that have @UnsupportedAppUsage but for which we don't
have any evidence of them currently being used, so should be safe to
remove from the unsupported list.
Bug: 170729553
Test: Treehugger
Change-Id: I4c8fd0006f950de9955242e93968fb0996ceb372
Refactoring to avoid paying the cost of extra StringBuilder that are
quickly disposed.
Bug: 170978902
Test: none
Exempt-From-Owner-Approval: trivial refactoring
Change-Id: Icd914a63cdadf8123c1e5a5073f85245f0791f0b
The recently-built Error Prone checker has found many instances where
we're always paying the cost of StringBuilder concatenation, even in
the typical cases where preconditions are successfully met.
Benchmarks have shown that even when replacing these with varargs
formatter strings, the default case is 20x faster.
Bug: 170978902
Test: none
Exempt-From-Owner-Approval: trivial refactoring
Change-Id: If8c00bc73467bfb91ec16c162969c9d26ca53646
In SQLiteQueryBuilder, allow empty tokens when checking for invalid
tokens during the strict grammar check.
Fixes: 151151800
Fixes: 161769478
Test: atest SQLiteQueryBuilderTest#testStrictQueryEmptyToken
Change-Id: Iac1cdd643253fd186a164b863d65d6e92698fd38
(cherry picked from commit e409ec2492)
A few months ago MediaProvider forked SQLiteQueryBuilder and we
fixed bugs in how the new insert(), update(), and delete() methods
were executed, but those fixes never made their way back upstream.
This CL is a clean cherry-pick of existing logic.
Bug: 155149941
Test: atest android.database.sqlite.cts.SQLiteQueryBuilderTest
Change-Id: I00d2ee88539b12d27a2ed99fff0546d1e3543b0e
Otherwise we'd risk applying different arguments to active versus
future connections.
Bug: 152005629
Test: atest CtsDatabaseTestCases:android.database.sqlite.cts.SQLiteDatabaseTest
Change-Id: I6e83a47d9874825fd14940245412372ef9227e79
Developers have been able to register custom collators using syntax
like "SELECT icu_load_collation()", but collators are registered per
database connection.
Since we don't expose any details APIs for interacting with connection
pools directly, developers can end up with flaky behavior as their
queries rotate through the pool of connections, as only a subset of
connections will have their collation registered.
This solve this, we add a new execPerConnectionSQL() method to
ensure that a given statement is executed on all current and future
database connections.
Bug: 152005629
Test: atest CtsDatabaseTestCases:android.database.sqlite.cts.SQLiteDatabaseTest
Change-Id: I459fb7b18660d2a04eec92d1e9cc410d769e361d
Starting in R, there is a new public API overload that delivers a
flags argument. Some apps may be relying on a previous hidden API
that delivered a userId argument, and this change is used to control
delivery of the new flags argument in its place.
There are dozens of these hidden API users are in the system UID,
either in the system process or the Settings app, so we hard-code
giving them the legacy behavior, since refactoring would be messy
between internal and AOSP branches.
Also adjust incoming and outgoing method signatures to use slightly
more flexible Collection<Uri>, which has handy methods like
contains() and isEmpty().
Bug: 150939131
Test: atest --test-mapping packages/providers/MediaProvider
Test: atest FrameworksServicesTests:com.android.server.devicepolicy.DevicePolicyManagerTest
Exempt-From-Owner-Approval: trivial refactoring
Change-Id: If6a77449e19215cf1c60d4217e62fc04b0959bfc
As part of MediaProvider becoming a Mainline module, some partners
need to understand more details about what triggered a Uri change
notification. This helps listening apps avoid making expensive and
race-condition-prone calls back into MediaProvider; typically when
they're only interested in insert and delete operations. This change
uses the existing "flags" argument to communicate the reason.
This change adds overloads to ContentObserver for listening apps to
receive these flags. In addition, we add overloads that deliver a
clustered set of multiple Uris together in a single Binder transaction
to improve overall efficiency. (This matches well with the existing
CR.notifyChange() API that we added earlier this year, since they
both work with Iterable<Uri>.)
Tests to verify that we only collapse Uris together when all other
method arguments are identical.
Bug: 147778404, 144464323
Test: atest CtsDatabaseTestCases
Test: atest CtsContentTestCases:android.content.cts.ContentResolverTest
Test: atest FrameworksServicesTests:com.android.server.content.ObserverNodeTest
Test: atest --test-mapping packages/providers/MediaProvider
Change-Id: I0bbd8a8b4a898ab6f891d085de0ecb4d68cbe302
SQLite ships with a handful of basic functions, such as UPPER() as
a scalar function and MAX() as a aggregate function. We now have
several use-cases for adding custom functions, where it's otherwise
prohibitively expensive to perform post-processing on the returned
Cursor, as that requires copying processed data to yet another
MatrixCursor before returning to apps.
This change adds the ability for developers to register custom
scalar and aggregate functions on databases that they've opened;
some contrived examples are scalar functions like REVERSE() for
reversing a string, or aggregate functions like STDDEV().
To give developers the most flexibility, we use the Java functional
interfaces for defining these operations, as developers may already
be familiar with the contracts of those methods. This also opens
the door to quickly adapting existing code through utility methods
like BinaryOperator.minBy(Comparator).
Bug: 142564473
Test: atest CtsDatabaseTestCases:android.database.sqlite.cts.SQLiteDatabaseTest
Change-Id: I9fa0e60ec77bab676396729cc9cb8ba8aaf56224
Adjust Exception to more general Throwable, and add docs for
new ContentResolver and ContentProvider overloads. Also add docs
for default state of strict query options.
Bug: 131598520, 141227540, 147287177
Test: atest --test-mapping packages/providers/MediaProvider
Change-Id: Icb0153b8c8a352db39de301074e948bfaa676ddb
The bulk of the work needed to get MediaProvider building against
the "system_current" SDK surface has been slowly merged over the
last few months, and this change makes the last few adjustments.
This adds a new StorageVolumeCallback which is simpler version of
StorageEventListener that simply delivers the changed StorageVolume.
Move DownloadManager logic into a onMediaStoreDownloadsDeleted()
method which hides the implementation details of how the OS connects
with that implementation.
Make local copies of some ExifInterface parsing logic; they could
be added to the androidx version in an unbundled release. Make a
local copy of RedactingFileDescriptor, since it's only needed for
the next few weeks until FUSE is globally enabled.
Bug: 137890034
Test: atest --test-mapping packages/providers/MediaProvider
Change-Id: Ib416eb8724781bdd234c8b7d728dee8b695ad6ac
Existing annotations in libcore/ and frameworks/ will deleted after the migration. This also means that any java library that compiles @UnsupportedAppUsage requires a direct dependency on "unsupportedappusage" java_library.
Bug: 145132366
Test: m && diff unsupportedappusage_index.csv
Change-Id: I0c336de56bc4a041dc97ff9b7927f62f0b44b457
Merged-In: I0c336de56bc4a041dc97ff9b7927f62f0b44b457
Existing annotations in libcore/ and frameworks/ will deleted after the migration. This also means that any java library that compiles @UnsupportedAppUsage requires a direct dependency on "unsupportedappusage" java_library.
Bug: 145132366
Test: m && diff unsupportedappusage_index.csv
Change-Id: I0c336de56bc4a041dc97ff9b7927f62f0b44b457
We had hoped that SQLiteQueryBuilder could enforce some pretty strict
grammar rules, but there are apps depending on the full quirkiness
of what SQLite will allow, which is pretty much "expr" everywhere.
So we shift our strategy from a whitelist-style approach to a
blacklist-style one, where we're willing to let any valid keyword
be used _except_ for ones we know are rooted in abuse, such as
performing SELECT subqueries or relying on SQL injection to blur
the lines between well-defined clauses.
Bug: 146478800, 146482076
Test: atest --test-mapping packages/providers/MediaProvider
Change-Id: Ib57ceab0e229e01177cabd8277f3c989c817b10c
These custom collators are added by ./android/sqlite3_android.cpp,
so let callers use them.
Bug: 140666363
Test: atest android.database.sqlite.cts.SQLiteQueryBuilderTest
Change-Id: I6674b04afb5bbb5f9870329431549eca8e4f5bc6
go/cleanup-greylist-txt
These have already been greylisted, however due to bugs/omissions in the tooling have been kept in go/greylist-txt instead of being annotated in the code.
Bug: 137350495
Test: m
Change-Id: Id6c1f5e403a0e66edb1102ee45f3bf19f244fb09
Merged-In: Id6c1f5e403a0e66edb1102ee45f3bf19f244fb09
