revert part of the CL: Ia561135e974a44ad3e3774ecb23c6a3d0fc38176
and add it to ContentProvider.query() to force query execution
in worker thread, instead of having the main thread incur the cost
of query execution and potentially get ANR
Change-Id: I0ea8a170bd954a421f4ad825f8090319a83a5b2b
The issue is that our code often "executes" a query
on a background thread but iterates over the cursor
on the UI thread. Since we actually do the fetch
on moveToFirst or moveToNext, the query is in reality
often run on the UI thread and causes an ANR.
Change-Id: Ia561135e974a44ad3e3774ecb23c6a3d0fc38176
This also makes the 500ms logging threshold (over which is always
logged, and under which is sub-sampled) configurable via a
SystemProperty, which is mostly useful for interactive debugging when
lock contention is suspected, but could also be useful in the future
as a quick way to adjust this threshold for dogfooders, without code
changes.
Change-Id: I769069d8d870331d89a4aa3239ba50db806fe4d4
and database.close() should NOT set mPath to null.
a few other minor changes included in this CL
1. if it is memory database, no need to delete any file
2. if 2 threads are sharing the same connection, and if corruption occurs
on it, one thread closes the db and deletes db - while the other
thread is still using it. this can cause SQLITE_MISUSE error.
to prevent this, every method in SQLiteDatabse should make sure
db is open before exec'ing sql statements. bug:2531172
Change-Id: I4cb5ab8539f46d7f8b26c3f830d799adf46444b6
this will let us know which cursor is being finalized.
if the heapworker gets wedbed due to the close bug:2536922
then we will never see the warning and never know which cursor
caused this problem
Change-Id: I595cc1014ff7a1114079b33665c092c6a2f3a907
if insert statement doesn't succeed, last inserted rowid
shoudl return -1 - instead of returning rowid of the last
successful insert that may have occurred years before this most
recent insert statement failure.
Change-Id: Ia517292afd58fdb600da900e0ee01fe051d6e618
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
