History log of /frameworks/base/core/java/android/database/sqlite/SQLiteClosable.java
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
c3849200fa60b22ea583ba2a6f902d6a632a5e7e 09-Mar-2010 Vasu Nori <vnori@google.com> add more debug info to SQL section in bugreport

after this CL, adb bugreport will the following info (under SQL section
of each app's meminfo dump)

SQL
heap: 344 memoryUsed: 344
pageCacheOverflo: 67 largestMemAlloc: 50

DATABASES
Pagesize Dbsize Lookaside Dbname
1024 7 24 googlesettings.db
1024 26 110 talk.db
1024 11 0 (attached) transient_talk_db
1024 11 32 subscribedfeeds.db
1024 20 27 gservices.db

Change-Id: Iabd13be9793d9794137c60a045b84fa632f13498
/frameworks/base/core/java/android/database/sqlite/SQLiteClosable.java
9ffdfa0c238fce3b85741d7f6828fd484cd8f195 09-Mar-2010 Brad Fitzpatrick <bradfitz@android.com> Speed up ContentProvider.query() in simple case by ~30%

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
/frameworks/base/core/java/android/database/sqlite/SQLiteClosable.java
d3fe30134edbe17094a5b9ef21aa6662de451001 19-Feb-2010 Vasu Nori <vnori@google.com> add diagnostic info to help debug bug:2427686
/frameworks/base/core/java/android/database/sqlite/SQLiteClosable.java
3ef94e25b4c896ecaa85aa2c12b8863ecdf98df0 05-Feb-2010 Vasu Nori <vnori@google.com> use sqlite 3.6.22 to print and profile the sql statetements

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.
/frameworks/base/core/java/android/database/sqlite/SQLiteClosable.java
9066cfe9886ac131c34d59ed0e2d287b0e3c0087 04-Mar-2009 The Android Open Source Project <initial-contribution@android.com> auto import from //depot/cupcake/@135843
/frameworks/base/core/java/android/database/sqlite/SQLiteClosable.java
d83a98f4ce9cfa908f5c54bbd70f03eec07e7553 04-Mar-2009 The Android Open Source Project <initial-contribution@android.com> auto import from //depot/cupcake/@135843
/frameworks/base/core/java/android/database/sqlite/SQLiteClosable.java
54b6cfa9a9e5b861a9930af873580d6dc20f773c 21-Oct-2008 The Android Open Source Project <initial-contribution@android.com> Initial Contribution
/frameworks/base/core/java/android/database/sqlite/SQLiteClosable.java