When query() uses bulkQuery() and we know we're going to need some
metadata right afterwards (number of rows and column index of _id, if
present), just asked for it in the initial binder transaction instead
of immediately fetching it again.
Also, this defers loading column names until the client asks for them.
This gets down the simpler (and very common) use cases of
ContentProvider.query() down to 3 binder calls:
QUERY_TRANSACTION to android.content.ContentProvider$Transport
GET_CURSOR_WINDOW_TRANSACTION to android.database.CursorToBulkCursorAdaptor
CLOSE_TRANSACTION to android.database.CursorToBulkCursorAdaptor
More can still be done, but this is a good bite-sized first piece.
Change-Id: I7ad45949f53e0097ff18c2478d659f0f36929693
a bug in maintaining the cache caused these warnings. when the cache
is full, caching code in SQLiteDatabase dropped an entry from the cache
to accommodate the new one. and if the just-dropped one is not in use
that object got GC'ed and caused a finalizer warning. Calendar is one app
that didn't use ? for bindargs (sometimes) and noticed this bug in that app
Fix is to not add the new enry to cache if the cache is already full.
that will cause the app's close() to release the entry.
another common case where this finalizer warning occurs is when unittests run.
if the test does not close the database in tearDown(), it will cause
database object and the compiled sql statement cache within the database
obj get GC'ed which cause finalizer warnings.
finalizer shoudl not be called ever. add a warning to say that.
adeprecate a few members in SQLiteProgram.java. they should not
have had protected access level. shoudl be package.
Turns out the database is used a ton, and not particularly quickly, so
these were spamming the logs at their prior 100ms thresholds. Setting
it to 500ms now. (still sub-sampled, so should be ~5x less spammy...)
Because some apps make SQLite database names containing email
addresses, we take care not to log those email addresses in the
EventLog, so other apps with READ_LOGS access can't read them.
bug fix for 2419869 is the following
1. only one object can use the prepared statement object
(SQLiteCompiledSql in SQLIteProgram)
2. if two objects are requesting to use it, then create a new prepared
statement object for exclusive use by the newcomer and let it be
be finalized by the newcomer.
3. add mInUse flag to SQLiteCompiledSql - to be set when SQLiteProgram
requests it and to be released when that SQLiteProgram is done with it
a couple more changes included are
1. unitests to simulate bug # 2419869 (and the fix's repair to it)
2. better logging in SQLiteCloseable when it prints log messages
Previously, as somewhat expected, the top SQL statements showing up in
the SQL analysis dashboards from developer phones was just "COMMIT;"
statements, which is pretty uselessly ambiguous.
Now the logs for commit operations look like:
I/db_operation( 1249): [/data/data/com.google.android.gsf/databases/subscribedfeeds.db,COMMIT;DELETE FROM _deleted_feeds WHERE _sync_account=? AND _syn,461,com.google.process.gapps,100]
I/db_operation( 1290): [/data/data/com.android.providers.contacts/databases/contacts2.db,COMMIT;SELECT account_name, account_type FROM _sync_state,126,android.process.acore,100]
I/db_operation( 1249): [/data/data/com.google.android.gsf/databases/talk.db,COMMIT;INSERT OR REPLACE INTO providerSettings(value, name) VAL,252,com.google.process.gapps,100]
I/db_operation( 1377): [/data/data/com.android.providers.calendar/databases/calendar.db,COMMIT;SELECT localTimezone, minInstance, maxInstance FROM Calen,948,,100]
I/db_operation( 1377): [/data/data/com.android.providers.calendar/databases/calendar.db,COMMIT;SELECT begin-(minutes*60000) AS myAlarmTime, Instances.ev,82,,83]
It doesn't totally pin-point the offending code, but it should get us
most of the way there. We may enhance this logging again in the
future.
The forgotten parts from Id72f718c / d72f718c9c. Whoops.
Tested by watching a device's logcat -b events and observing no huge
or negative values. And this time with the right system.img file,
even!
Previously, SQLiteDatabase was using Debug.threadCpuTimeNanos(), which
doesn't include I/O time (user-perceived latency), and ContentResolver
was using System.currentTimeMillis(), which didn't account for deep
sleeps.
Now both are consistently using SystemClock.uptimeMillis().
instead of rolling our own trace/profile code in java, lets use
sqlite 3.6.22 features. turns out sqlite does a good job of
printing the sql statements - including the ones from the triggers.
capture the sql statement along with the bindargs passed in. this will help
one to see the sql statements being executed and hopefully will help
debug incorrect-sql bugs.
SQLiteDatabase.java has ConflictAlgorithm which allows callers to specify
actions to take when insert or update causes constraint violations.
These actions are documented at http://www.sqlite.org/lang_conflict.html.
why make these public? usecase is the following:
Gmail has a table with a column "_id" being the integer primary key and
they let sqlite assign key values to the column.
but there is another UNIQUE key column (message_id) in the table.
so an insert could fail due to constraint violation on the message_id column
(i.e., not on the primary key). and when that happens, they would like to
get the value of _id that caused constraint violation.
currently hidden method insertOnConflict() already provides the above
functionality. that means exposing ConflictAlgorithm also.
The MMS code has been moved into the mms-common library.
Move SqliteWrapper (and make it hidden) into the database
directory because Telephony.java depends on it. Create a mmscommon
library similar to androidcommon for a number of files used both
by the telephony layer, by mms, and by myfaves.
Change-Id: I2e23e87c4961b87c42a4c8a63f812fa9e0e44dec
when the compiled-sql cache is full, print the warning only a few times and
after that, if the condition persists, clear the cache.
don't flood the cache with the same warning million times.
this is a clone of https://android-git.corp.google.com/g/#change,35174.
if the cache is full to its capacity and if a new statement is to be cached,
one of the entries in the cache is thrown out to make room for the new one.
but the one that is thrown out doesn't get deallocated by SQLiteProgram
because it doesn't know that it should.
fixed this by having SQLiteProgram finalize its sql statement in
releaseReference*() methods, if the statement is not in cache.
currently, an exception is thrown if SQLiteCursor object is being
finalized before the cursor is closed. instead of an exception, simply
log an error message.
some android team members look at the exception and think it is catastrophic.
Merge commit '328c0e7986aa6bb7752ec6de3da9c999920bb55f' into eclair-mr2-plus-aosp
* commit '328c0e7986aa6bb7752ec6de3da9c999920bb55f':
- removed the concept of Entity from the ContentProvider APIs
dealloc compiled-sql statements before removing references of SQLiteClosable objects from SQLiteDatabase obj. otherwise, code will attempt to close database before deallocing the compiled-sql statements and that causes sqlite exceptions.
to a race condition) that breaks the caching of non-existent Settings/Secure/
Gservices values (causing lots of unnecessary database queries).
Fix a dumb thinko (reversed condition) in the SQLiteDatabase logging.
- always enable the log, but subsample for queries faster than 100ms
- add information about whether it's blocking a main thread
- log the entire sql (have not yet added quoted-string-stripping)
