By adding these stubs, they will be automatically added to framework.aidl
in sdk builds.
This makes it easier for unbundled apps to pass these objects across
AIDL calls.
ContentValues & CursorWindow are already public Parcelables. It is an
oversight that they were not already in framework.aidl.
There are a lot of other public Parcelables that are missing from
framework.aidl. This just fixes two commonly requested ones.
Change-Id: If61e19b1206da1680413d9ea03de87a90b6d233e
Application Devleopers are using queryNumEntries API
implemented by "COUNT(*)" to check whether a table is empty or not.
COUNT(*) has to process the entire table to compute the result.
But, "EXISTS" can stop after a single matching row has been found.
So, Using "EXISTS" is more faster than "COUNT(*)"
I added new API using "EXISTS" to check whether a table is empty or not
Change-Id: Idcc2633d0a5349c59f41e125cf34c9dc6622cdbe
# By Tim Roes
# Via Android Git Automerger (1) and others
* commit '4fd60792473711a10dc9b27faa1a35efe9e4d6a0':
Complete documentation of whereArgs (Issue #43061)
# By László Dávid
# Via Android Git Automerger (2) and others
* commit '2990ed7a3bf7314bbd4d98161fbcdcf48098052c':
NullPointerException in SQLiteSession
# By Niklas Brunlid
# Via Android Git Automerger (2) and others
* commit '4e68024c7e9cf5849bc7c57266b0079113a2562f':
Keep native callbacks when primary SQLiteConnection is recreated
Complete the missing documentation for the
whereArgs argument in delete, update and
updateWithOnConflict
Update: Removed trailing spaces
Change-Id: I451ec9e0747c7655c612a4506f40152af0adcf3a
Signed-off-by: Tim Roes <tim.roes88@googlemail.com>
Ensure that the Cursor object is closed if a query on a
content provider fails due to an error or is canceled during
execution. There are several places in the code where
similar problems can occur.
To further reduce the likelihood of leaks, close the cursor
window immediately when a query fails.
Bug: 7278577
Change-Id: I8c686c259de80a162b9086628a817d57f09fdd13
When a database was ATTACHed/DETACHed to a database that had Write-Ahead
Logging enabled, the primary SQLConnection was recreated but the
registered native callbacks were not restored.
Change-Id: I8787fee78e68197ae472e05cc694d11381defa71
Many media files and source code files were marked as executable in Git.
Remove those.
Also a shell script and python script were not marked as executable.
Change-Id: Ieb51bafb46c895a21d2e83696f5a901ba752b2c5
The reason for this is a bit subtle: we want to guarantee that
when a content observer is registered using the public API, it
is *always* bound to the host user's view of the data behind the
observed Uri, never the calling user's. Now, the reason it was
the calling user in the first place is that the Settings provider
(and potentially any singleton provider) needs the observers
underlying Cursors returned from query() to be tied to the caller's
user, not the provider's host user.
In order to accomplish that now that the public-facing behavior is
always tied to the host user, the concrete class that implements
the Cursor type handled by the Settings provider has been extended
with a new hidden API for setting a notification observer tied to
an arbitrary user; and then the provider explicitly downcasts the
query result's Cursor to that class in order to register the
notification observer. We can do this safely because this is platform
code; if we change the way that these underlying cursors are constructed,
we can just fix this point of call to follow along. If they get out
of sync in the future, the Settings provider will scream bloody
murder in the log and throw a crashing exception.
Bug 7231549
Change-Id: I0aaceebb8b4108c56f8b9964ca7f9e698ddd91c8
In current code, if an application opens a cursor to access a
provider, and doesn't close that cursor, later, when this cursor
is garbage collected, it won't get closed. This will cause a memory
leak in the provider. The leaked memory can only be reclaimed when
the application with the leaked cursor was dead.
The solution is, close the cursor when it's garbage collected.
Change-Id: I786915c46d4672b6b1b37414b3bc1ff8cea2e00b
This class does not offer any advantages over SQLiteStatement
and just makes code more complex and error-prone.
Documented that the class is not thread-safe.
Removed a potential deadlock in insert() and replace() caused
by the insertInternal() method being synchronized in the case
where the class was being used concurrently (woe to you!).
Thread A would start a transaction.
Thread B would call insertInternal() and acquire the object monitor,
but block because it could not obtain the db connection because
thread A is holding onto it.
Thread A would call insertInternal() and block because Thread B
was holding the object monitor.
Deadlock.
Changed this code to use a transaction instead of a lock,
which provides the necessary mutual exclusion guarantee without
the potential for a deadlock. Even so, the class really isn't
thread safe.
Bug: 6625094
Change-Id: I51d9a15567a6f2bad6f25e550b48f8f6ffcab2a7
This change does not alter the behavior of the system except to
enable the use of system properties to override SQLite configuration
options for debugging.
Bug: 6484633
Change-Id: I8908a3ba07910a1193396e2e45791e9faa7be349
If the db connection had been marked read-only, then certain
operations performed during reconfiguration, such as setting the
locale, could fail. So we need to make sure to clear the
read-only flag ahead of time.
Bug: 6296752
Change-Id: I98e19aff6386497b7fc321e04ca560fc1817a781
Also provide a lifecycle method on SQLiteOpenHelper so that
applications can configure things like this before the onCreate,
onUpgrade, onDowngrade and onOpen callbacks run.
Change-Id: If3d1396720bd2e032dd9e034733fb1ff9a9733dd
Using enableWriteAheadLogging() to enable WAL is inefficient because
we previously disabled WAL mode when the database was opened.
Switching from WAL to PERSIST then back to WAL is inefficient
and could slow down application launch time. It would be better
to leave the database in WAL mode when we open it to begin with.
To do that, we need to know ahead of time whether we will want to
have WAL enabled for the newly opened database.
Using this flag also reduces the chance that we will encounter
an error enabling WAL mode due to there being other open connections
to the database.
Bug: 6124556
Change-Id: I38ec7a528baeda9f1ef77e25e88b3ca4b6296200
Because we always disable WAL mode when a database is first opened
(even if we intend to re-enable it), we can encounter problems if
there is another open connection to the database somewhere.
This can happen for a variety of reasons such as an application opening
the same database in multiple processes at the same time or if there is a
crashing content provider service that the ActivityManager has
removed from its registry but whose process hasn't quite died yet
by the time it is restarted in a new process.
If we don't change the journal mode, nothing really bad happens.
In the worst case, an application that enables WAL might not actually
get it, although it can still use connection pooling.
Bug: 6124556
Change-Id: Ia2ffdbbc8f82721b170f3bf71bd5242dfd56d9ac
Changing WAL mode requires obtaining an exclusive lock on the
database and can only be done when there are NO other active
database connections.
Check that this is really the case, and bail with a useful
error message if an application attempts to change WAL mode while
transactions are in progress.
Expose disableWriteAheadLogging() in the API.
Change-Id: I87599de3b88c53dcd75677aefd72e40de216c2c1
Make the database opening code more robust in the case of
read-only database connections.
Check whether a PRAGMA needs to be issues before doing it.
Mostly it's harmless but it can grab a transaction on the
database unnecessarily.
Change-Id: Iab2cdc96c785e767f82966b00597e19337163f2f
If the remote end of a bulk cursor died, then it was possible
for getColumnNames() to return null, violating the invariant
that it never returns null. As a result, the application could
crash in strange ways due to an NPE.
Since we are often interested in the column names anyhow, prefetch
them when setting up the bulk cursor adaptor. This way, a
remote cursor will never return null even if the remote end died.
It is possible for an application to continue to use a remote cursor
even after the provider has died unless it needs to requery it
for some reason. Of course at that point, bad things will
happen... but usually the app is better prepared for it than
if it just randomly encounters a null array of column names.
This change also optimizes the bulk cursor adaptor to return the
initial cursor window back to the client, potentially saving
an extra RPC. Because the communication protocol between
the CursorToBulkCursorAdaptor and BulkCursorToCursorAdaptor was
getting a little hard to follow, introduced a new type called
BulkCursorDescriptor to hold all of the necessary parameters.
Deleted several unnecessary IBulkCursor methods that are never
actually called remotely.
Bug: 6168809
Change-Id: I9aaf6f067c6434a575e2fdbf678243d5ad10755f
SQLiteDatabase.close() should call releaseReference() rather than
closing the database immediately. SQLiteDatabase should also hold
a reference to itself while performing certain operations to
ensure that they complete normally even if another thread closes
the database at the same time.
Fixed a couple of missing or redundant uses of acquireReference()
related to CursorWindows.
To be honest, the reference counting performed by SQLiteClosable should
not be needed, but we're stuck with it in the API.
Bug: 6104842
Change-Id: I3444a697409905d4a36b56418dc7766f5ba76b59
The SQLiteDatabase constructor is inaccessible so it is not
possible for applications to subclass it. To remove all possible
remaining temptation to do so, make the class final.
Change-Id: I4148e9b06f0661ec22aab8e45afde38498d2375a
This change leaves the sync mode at FULL for both WAL and non-WAL
but makes it easy to change it for one but not the other.
To reduce the number of synchronous writes, it might make sense to
change the sync mode for non-WAL to NORMAL instead of FULL which
should be just as safe.
On the other hand, the sync mode for WAL should probably remain FULL
because there may be an impact on transaction durability otherwise.
Initial experiments show that there might not be a significant
performance benefit to using NORMAL, but we may revisit this later.
Change-Id: Ifcd55bedcfefa6600974c2295ca5d4163b408cbf
Add SQLiteDatabase.deleteDatabase to delete a database and all
of its auxiliary files.
This method is also used by Context.deleteDatabase and resolves issues
where auxiliary files would get left behind.
Bug: 5972489
Change-Id: I3633b9b4978972a1d240ac0a9861420ecf989149
Moved more configuration into config.xml so we can tweak settings
like the default journal mode, WAL auto-checkpoint interval and
so on.
This change itself should not introduce any functional differences.
Change-Id: Id6c95fa25b116ce47e8ae49cd8a80d52b1c0dd80
Combine the code for opening readable and writable databases.
This improves the handling of the case where a database cannot
be opened because it cannot be upgraded. Previously we would
open the database twice: first read-write, then read-only, each
time failing due to the version check. Now only open it once.
Removed the goofy locking logic related to upgrading a read-only
database to read-write. We now do it in place by reopening the
necessary connections in the connection pool.
Change-Id: I6deca3fb90e43f4ccb944d4715307fd6fc3e1383
