987f79f60bb1f0a4bcd3ef22e57301c743f0b94f |
|
19-Nov-2014 |
Andreas Gampe <agampe@google.com> |
Frameworks/base: Replace LOG_FATAL_IF in core/jni Do not use LOG_FATAL_IF in JNI setup. This is one-time on startup and important enough to always check. Add a header with common helper definitions. Move to inlined functions instead of macros to clean up the code. Change-Id: Ib12d0eed61b110c45d748e80ec36c563e9dec7e5
/frameworks/base/core/jni/android_database_CursorWindow.cpp
|
853940331ff2be48ed3e63f459845e5e43d0a131 |
|
16-Apr-2014 |
Mark Salyzyn <salyzyn@google.com> |
frameworks: 64 bit compile issues ToDo: core/jni/com_android_internal_net_NetworkStatsFactory.cpp (merge issues) Change-Id: I5cf0bbb868e6c18e86c97c6491b6ee983a8ee1a2
/frameworks/base/core/jni/android_database_CursorWindow.cpp
|
738702d28ab7e0e89e3c6e18fd46cc1361917eb9 |
|
02-Jan-2014 |
Ashok Bhat <ashok.bhat@arm.com> |
AArch64: Use long for pointers For storing pointers, long is used in CursorWindow and SQLiteConnection classes as native pointers can be 64-bit. Change-Id: Ia686006a7b8bdc7b95e5de0d0a294b155034a921 Signed-off-by: Ashok Bhat <ashok.bhat@arm.com> Signed-off-by: Marcus Oakland <marcus.oakland@arm.com> Signed-off-by: Kévin PETIT <kevin.petit@arm.com>
/frameworks/base/core/jni/android_database_CursorWindow.cpp
|
d84e1ce0b535128f03416145554fb405f9fade3e |
|
07-Mar-2012 |
Jeff Sharkey <jsharkey@android.com> |
Split Parcel JNI details away from Binder. This is purely a refactoring, with no change to the underlying functionality. Change-Id: I41b59f14e57d1cc144274a01f77658d99a1bfe02
/frameworks/base/core/jni/android_database_CursorWindow.cpp
|
49d2b1864c3dfec6faff74d67cb2527a8f1af5a8 |
|
28-Feb-2012 |
Mathias Agopian <mathias@google.com> |
move CursorWindow from libbinder to libandroidfw Change-Id: I3b304e4f74e0d0ec8b20c57296c62449c9a0f792
/frameworks/base/core/jni/android_database_CursorWindow.cpp
|
e5360fbf3efe85427f7e7f59afe7bbeddb4949ac |
|
01-Nov-2011 |
Jeff Brown <jeffbrown@google.com> |
Rewrite SQLite database wrappers. The main theme of this change is encapsulation. This change preserves all existing functionality but the implementation is now much cleaner. Instead of a "database lock", access to the database is treated as a resource acquisition problem. If a thread's owns a database connection, then it can access the database; otherwise, it must acquire a database connection first, and potentially wait for other threads to give up theirs. The SQLiteConnectionPool encapsulates the details of how connections are created, configured, acquired, released and disposed. One new feature is that SQLiteConnectionPool can make scheduling decisions about which thread should next acquire a database connection when there is contention among threads. The factors considered include wait queue ordering (fairness among peers), whether the connection is needed for an interactive operation (unfairness on behalf of the UI), and whether the primary connection is needed or if any old connection will do. Thus one goal of the new SQLiteConnectionPool is to improve the utilization of database connections. To emulate some quirks of the old "database lock," we introduce the concept of the primary database connection. The primary database connection is the one that is typically used to perform write operations to the database. When a thread holds the primary database connection, it effectively prevents other threads from modifying the database (although they can still read). What's more, those threads will block when they try to acquire the primary connection, which provides the same kind of mutual exclusion features that the old "database lock" had. (In truth, we probably don't need to be requiring use of the primary database connection in as many places as we do now, but we can seek to refine that behavior in future patches.) Another significant change is that native sqlite3_stmt objects (prepared statements) are fully encapsulated by the SQLiteConnection object that owns them. This ensures that the connection can finalize (destroy) all extant statements that belong to a database connection when the connection is closed. (In the original code, this was very complicated because the sqlite3_stmt objects were managed by SQLiteCompiledSql objects which had different lifetime from the original SQLiteDatabase that created them. Worse, the SQLiteCompiledSql finalizer method couldn't actually destroy the sqlite3_stmt objects because it ran on the finalizer thread and therefore could not guarantee that it could acquire the database lock in order to do the work. This resulted in some rather tortured logic involving a list of pending finalizable statements and a high change of deadlocks or leaks.) Because sqlite3_stmt objects never escape the confines of the SQLiteConnection that owns them, we can also greatly simplify the design of the SQLiteProgram, SQLiteQuery and SQLiteStatement objects. They no longer have to wrangle a native sqlite3_stmt object pointer and manage its lifecycle. So now all they do is hold bind arguments and provide a fancy API. All of the JNI glue related to managing database connections and performing transactions is now bound to SQLiteConnection (rather than being scattered everywhere). This makes sense because SQLiteConnection owns the native sqlite3 object, so it is the only class in the system that can interact with the native SQLite database directly. Encapsulation for the win. One particularly tricky part of this change is managing the ownership of SQLiteConnection objects. At any given time, a SQLiteConnection is either owned by a SQLiteConnectionPool or by a SQLiteSession. SQLiteConnections should never be leaked, but we handle that case too (and yell about it with CloseGuard). A SQLiteSession object is responsible for acquiring and releasing a SQLiteConnection object on behalf of a single thread as needed. For example, the session acquires a connection when a transaction begins and releases it when finished. If the session cannot acquire a connection immediately, then the requested operation blocks until a connection becomes available. SQLiteSessions are thread-local. A SQLiteDatabase assigns a distinct session to each thread that performs database operations. This is very very important. First, it prevents two threads from trying to use the same SQLiteConnection at the same time (because two threads can't share the same session). Second, it prevents a single thread from trying to acquire two SQLiteConnections simultaneously from the same database (because a single thread can't have two sessions for the same database which, in addition to being greedy, could result in a deadlock). There is strict layering between the various database objects, objects at lower layers are not aware of objects at higher layers. Moreover, objects at higher layers generally own objects at lower layers and are responsible for ensuring they are properly disposed when no longer needed (good for the environment). API layer: SQLiteDatabase, SQLiteProgram, SQLiteQuery, SQLiteStatement. Session layer: SQLiteSession. Connection layer: SQLiteConnectionPool, SQLiteConnection. Native layer: JNI glue. By avoiding cyclic dependencies between layers, we make the architecture much more intelligible, maintainable and robust. Finally, this change adds a great deal of new debugging information. It is now possible to view a list of the most recent database operations including how long they took to run using "adb shell dumpsys dbinfo". (Because most of the interesting work happens in SQLiteConnection, it is easy to add debugging instrumentation to track all database operations in one place.) Change-Id: Iffb4ce72d8bcf20b4e087d911da6aa84d2f15297
/frameworks/base/core/jni/android_database_CursorWindow.cpp
|
5a05c23f3d6a1a895bf5917aacd8bd9a5302ba00 |
|
12-Jan-2012 |
Jeff Brown <jeffbrown@google.com> |
Clean up database tests a little bit. Change-Id: Ib05c699bf59187cb51627b5f352c2a15ad2c28bb
/frameworks/base/core/jni/android_database_CursorWindow.cpp
|
3762c311729fe9f3af085c14c5c1fb471d994c03 |
|
06-Jan-2012 |
Steve Block <steveblock@google.com> |
Rename (IF_)LOGE(_IF) to (IF_)ALOGE(_IF) DO NOT MERGE See https://android-git.corp.google.com/g/#/c/157220 Bug: 5449033 Change-Id: Ic9c19d30693bd56755f55906127cd6bd7126096c
/frameworks/base/core/jni/android_database_CursorWindow.cpp
|
650de3dcfcbc7635da3c070410ef1dc4027ae464 |
|
27-Oct-2011 |
Jeff Brown <jeffbrown@google.com> |
Optimize fillWindow to improve reverse-seek performance. Bug: 5520301 When an application requests a row from a SQLiteCursor that is not in the window, instead of filling from the requested row position onwards, fill from a little bit ahead of the requested row position. This fixes a problem with applications that seek backwards in large cursor windows. Previously the application could end up refilling the window every time it moved back one position. We try to fill about 1/3 before the requested position and 2/3 after which substantially improves scrolling responsiveness when the list is bound to a data set that does not fit entirely within one cursor window. Change-Id: I168ff1d3aed1a41ac96267be34a026c108590e52
/frameworks/base/core/jni/android_database_CursorWindow.cpp
|
5e5d6d8ba04d7579df840cda055cd5dfa9d7666f |
|
13-Oct-2011 |
Jeff Brown <jeffbrown@google.com> |
Deprecate local-only CursorWindows. There is no difference and has never really been a difference between local-only and remotable CursorWindows. By removing the distinction officially in the API, we will make it easier to implement CrossProcessCursor correctly. CrossProcessCursor is problematic currently because it's not clear whether a call to getWindow() will return a local-only window or a remotable window. As a result, the bulk cursor adaptor has special case handling for AbstractWindowedCursors vs. ordinary CrossProcessCursors so that it can set a remotable window before the cursor fills it. All these problems go away if we just forget about local-only windows being special in any way. Change-Id: Ie59f517968e33d0ecb239c3c4f60206495e8f376
/frameworks/base/core/jni/android_database_CursorWindow.cpp
|
0cde89f5f025b7826be009ebb9673b970e180e32 |
|
10-Oct-2011 |
Jeff Brown <jeffbrown@google.com> |
Use ashmem for CursorWindows. Bug: 5332296 The memory dealer introduces additional delays for reclaiming the memory owned by CursorWindows because the Binder object must be finalized. Using ashmem instead gives CursorWindow more direct control over the lifetime of the shared memory region. The provider now allocates the CursorWindows and returns them to clients with a read-only protection bit set on the ashmem region. Improved the encapsulation of CursorWindow. Callers shouldn't need to care about details like how string fields are allocated. Removed the compile-time configuration of string and numeric storage modes to remove some dead weight. Change-Id: I07c2bc2a9c573d7e435dcaecd269d25ea9807acd
/frameworks/base/core/jni/android_database_CursorWindow.cpp
|
715311fa5aeb39fd0904209e1428a3656c721c3d |
|
07-Oct-2011 |
Jeff Brown <jeffbrown@google.com> |
Fix regression in CursorWindow.getString() Bug: 5332296 NewStringUTF expects modified UTF-8, so it barfs on UTF-8 strings that contain high codepoints. Even though it results in an extra copy being performed, first convert to UTF-16, then call NewString. Change-Id: Idbfeb3cc2c4b731834e4482848dcac2fa33ec2d0
/frameworks/base/core/jni/android_database_CursorWindow.cpp
|
d0ff68da6a606602235fb8749473999e3d1bde53 |
|
07-Oct-2011 |
Jeff Brown <jeffbrown@google.com> |
Fix regression in CursorWindow.copyStingToBuffer. Bug: 5332296 Change-Id: Iff9eed786f0a8293b6156f883a66a322ddad5e99
/frameworks/base/core/jni/android_database_CursorWindow.cpp
|
aa32c30b81134fc7ebd9408f4757d1dc4410f338 |
|
07-Oct-2011 |
Jeff Brown <jeffbrown@google.com> |
Restore broken CursorWindow.getType behavior. Bug: 5430009 Some CTS tests try to call getType on fields in empty cursor windows or with out of bound column indices (-1). Restoring the previous behavior of returning FIELD_TYPE_NULL instead of throwing. Fix this later. Change-Id: I782bd02012474e7dabc5bb7ea2dc45e8b0c7ef25
/frameworks/base/core/jni/android_database_CursorWindow.cpp
|
3bc6bbc92cd2095f42039b5aadd0a14d0e5d9230 |
|
06-Oct-2011 |
Jeff Brown <jeffbrown@google.com> |
Clean up CursorWindow code. Bug: 5332296 The code is functionally equivalent, but a little more efficient and much easier to maintain. Change-Id: I90670a13799df05831843a5137ab234929281b7c
/frameworks/base/core/jni/android_database_CursorWindow.cpp
|
f786b6ca5df079f5cc84838251137f9b65ae10c9 |
|
01-Sep-2011 |
Jeff Brown <jeffbrown@google.com> |
Fix JNI leak in copyStringToBuffer Bug: 5244396 Code was acquiring the char array twice for FIELD_TYPE_INTEGER or FIELD_TYPE_FLOAT but only releasing it once. Removed the redundant calls to GetCharArrayElements. Change-Id: If767d3295d5a663a823e5ca0cd979379a3ccd024
/frameworks/base/core/jni/android_database_CursorWindow.cpp
|
e6044145bccf30e2b1785eb33a26de6496167986 |
|
25-Feb-2011 |
Vasu Nori <vnori@google.com> |
bug:3467948 if byteArray couldn't be allocated for blob, throw exception Change-Id: I73e36c10f31086ea567debad536350316b2df67f
/frameworks/base/core/jni/android_database_CursorWindow.cpp
|
6141e13f6e84846ae531358a8bcbf6d2102b1bd4 |
|
24-Dec-2010 |
Vasu Nori <vnori@google.com> |
when cursorwindow allocation fails, print the number of cursors left open the reason for bug:3281533, bug:3127159 is probably too many cursors are left un-closed in the process. print the info on the number of cursors left open when the exception "cursorwindow allocation failed" occurs. This should help us figure out if that indeed is the reason and which process is leaving the cursors open. Change-Id: I4b46be63f5dfbe9b102ad7a9cf9dd21e70f71e14
/frameworks/base/core/jni/android_database_CursorWindow.cpp
|
34ad57f0e844cd97f59d4ab22087d60d58650ba4 |
|
21-Dec-2010 |
Vasu Nori <vnori@google.com> |
resubmitting Change-Id: I67b1d04a5c9fc18b0cd4da6184d0b814b64d89e9 Change-Id: I67b1d04a5c9fc18b0cd4da6184d0b814b64d89e9 was reverted due to a bug. fixed the bug and resubmitting it here
/frameworks/base/core/jni/android_database_CursorWindow.cpp
|
5274e84e88d2cba20ad3cb21c55c1758b4da8af4 |
|
20-Dec-2010 |
Vasu Nori <vnori@google.com> |
Revert "bug:2448371 cursorwindow size moved to resource xml file." This reverts commit 2594bae1f551d758c5c88771310d1ee3dc2c71ac.
/frameworks/base/core/jni/android_database_CursorWindow.cpp
|
2594bae1f551d758c5c88771310d1ee3dc2c71ac |
|
19-Dec-2010 |
Vasu Nori <vnori@google.com> |
bug:2448371 cursorwindow size moved to resource xml file. let cursor window size be set per device in device resources file. default is 1MB. for SR, it is 2MB. it can be set to any value (in kB) in the device resource strings.xml file Change-Id: I67b1d04a5c9fc18b0cd4da6184d0b814b64d89e9
/frameworks/base/core/jni/android_database_CursorWindow.cpp
|
b37f8a8af15425ed3e65104e8556099d33a9c1ce |
|
29-Nov-2010 |
Vasu Nori <vnori@google.com> |
fix messages from sqlite layer in c++ code to be useful. Change-Id: Ib13f86f3481aae391f5e887bb14877f12bf48034
/frameworks/base/core/jni/android_database_CursorWindow.cpp
|
0a2c6cc0138ceac8164061b3cdc3758441916c18 |
|
15-Jun-2010 |
Vasu Nori <vnori@google.com> |
fix bugs introduced by I3ef1bcdb2eb1c45f68e829ccb6e3ecde28076591 two bugs were introduced by the above CL 1. to test if the column value is NULL, getType_native() should check if the columnindiex is valid. (it seems sometimes callers could ask if a given non-existent column is null - and the answer should be true.) 2. if a column is null and isBlob_native, isString_native methods should return true - not false. Change-Id: I64df75d0a3840a4502c00db8759c66ba4b268a26
/frameworks/base/core/jni/android_database_CursorWindow.cpp
|
8b0dd7da360d70920a37802eb455ba41500d3b45 |
|
18-May-2010 |
Vasu Nori <vnori@google.com> |
add API to Cursor to get column value type Change-Id: I3ef1bcdb2eb1c45f68e829ccb6e3ecde28076591
/frameworks/base/core/jni/android_database_CursorWindow.cpp
|
2807df89af680e46cb35ee0035bb10b42d3136a2 |
|
27-May-2010 |
Mike Lockwood <lockwood@android.com> |
Move CursorWindow class from core/jni to libbinder To allow use of the native CursorWindow class outside of the core framework jni Change-Id: I72e8dcb91a2c691130c33cdfd9a25d343da1c592 Signed-off-by: Mike Lockwood <lockwood@android.com>
/frameworks/base/core/jni/android_database_CursorWindow.cpp
|
03d9490758c9318cee6d14d3cc5007556dce92d0 |
|
22-May-2009 |
Fred Quintana <fredq@google.com> |
- create a new generic ISyncAdapter implementation, SyncAdapterNew - change the applyBatch to take an ArrayList rather than an [] - change Entity to be a final flass that contains ContentValues - remove the ability to update/insert Entities by a ContentProviderOperation
/frameworks/base/core/jni/android_database_CursorWindow.cpp
|
9066cfe9886ac131c34d59ed0e2d287b0e3c0087 |
|
04-Mar-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //depot/cupcake/@135843
/frameworks/base/core/jni/android_database_CursorWindow.cpp
|
d83a98f4ce9cfa908f5c54bbd70f03eec07e7553 |
|
04-Mar-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //depot/cupcake/@135843
/frameworks/base/core/jni/android_database_CursorWindow.cpp
|
54b6cfa9a9e5b861a9930af873580d6dc20f773c |
|
21-Oct-2008 |
The Android Open Source Project <initial-contribution@android.com> |
Initial Contribution
/frameworks/base/core/jni/android_database_CursorWindow.cpp
|