- Move PackageInfo out of ActivityThread, renaming to LoadedApk.
- Rename some of the other PacakgeInfo inner classes to better
represent what they are.
- Rename HistoryRecord to ActivityRecord.
- Introduce AppGlobals, to eventually let ActivityThread become
package scoped.
Change-Id: Ib714c54ceb3cdbb525dce3db9505f31042e88cf0
SQLite is JNI to native code and doesn't go via IFileSystem, so it
needs custom sprinkling, at least for now.
Change-Id: Ic7fded1b64a4f483dfc17b3a7b136c803df1e111
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().
