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
Bug #6196903
Whenever a memory flush happens, the GL renderer discards some or all of its
font caches. Each font cache holds an array of vertex indices that was
initially designed to have the same life cycle as the process. This changed
when memory flushes were introduced but this array was never taken care of
in the destructor.
Change-Id: Ief124f609ea55b671c0a9b43637d9e013629ebaa
Animations that were started from AppWindowToken.showAllWindowsLocked
were not setting mInnerFields.mAnimating and hence the animations were
not progressing. This resulted in popups such as menus and time/date
settings not showing up.
Fixes bug 6205076.
Change-Id: I4daae5895e64182328671e282331f14dd5561d5e
The new DisplayList properties functionality does not currently handle Animation
(android.view.animation) functionality, so we fall back to the previous approach
of redrawing the DisplayList when an Animation changes alpha/transform data for
a View. The DL code was not, however, correctly using that logic, so that
the Animation transform information was being ignored, or at least not set
correctly on the DisplayList during redraws.
This fix accounts for Animation changes and sets up the DisplayList correctly.
Change-Id: I9f6e0382b05d0627f4779f30e74641dedcc77f82
A new test had been added to performDraw to provide an early return if
the screen was off. Drawing should have proceeded however if
mReportNextDraw is set. Otherwise views that turn on the screen (such
as the alarm) are not shown.
Fixes bug 6168158.
Change-Id: If9013d9dbd39d60ee1de8aeb3e0c1facbc5a7db5
Interdepends on https://android-git.corp.google.com/g/170037
Tidys up a TODO from my webview proxy patch.
This allows me to re-introduce getWebView(), but now returning the
actual WebView instance which is needed by my upcoming change to WebKit
linked above.
Also moves sendPluginDrawMsg() to WebViewCore for convenience in the
MediaTexture code that calls this.
Change-Id: I57b72504a792de58d15f386abf4a9d821449ab0a
