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
Fixes a crash that would occur if an app with a pending backup
pass in the pipeline was updated to remove its agent declaration
from the manifest (or other more esoteric ways that a backup
pass was expected to run for an app without their own agent).
Bug 5776591
Change-Id: I5a8bc8c12de6a2bfa82f5093fe3a15b754109ab1
ZipUtils is needed by build/tools, move it from libandroidfw
(frameworks/base) to libutils (frameworks/native).
Change-Id: I2b4b7adcdf68eb25ee7cba5dd3b69eadf0523af3
There is no need to enable WAL for the WebView database because it
does not require high throughput.
Enabling WAL increases memory usage and can also cause problems if
the same database is opened in multiple processes, which can happen
if an application has UI code running in multiple processes. Normally,
we would use a content provider to ensure that the database is only
opened within one process (and then accessed remotely view RPC), but
we can't do that for WebView because it is part of the framework.
Deleted the call to setLockingEnabled. It does nothing.
Bug: 6124556
Change-Id: Ic397c74872fe6b1246da0c859eab0d5147045c86
Introduction of the class WindowAnimator which takes care of all
animations stepping and Surface operations.
Change-Id: I78f1c269fa57df0616c08adbe156e3059709ae48
A long press on a list item in ResolverActivity (shown when users are
asked to choose an activity to complete an action) will now open
the app detail settings for the package providing that item.
This is a work in progress; awaiting more UX input on other changes
and better discoverability of this feature.
Change-Id: I2cc07c5520fdd23cf1a43f169b114295f5d9d0ac
* changes:
Merge commit '74803dc'
add config_bluetooth_default_profiles config var and use it to disable bt profiles
Do not allow Surface creation on machines without SurfaceFlinger We will fail later anyways, but this change makes it much easier to track down places where we are inadvertently doing operations that depend on the flinger.
fix setting only usb mode
Detect (at runtime) kernel support for the "hdmi_audio" switch.
Add a config resource to disable key-chord screenshotting
Do not assume that there is always a running activity (Necessary for headless devices)
Add batch volume adjust support to adjustMasterVolume() in AudioManager and AudioService.
For devices that don't care about the previously default bluetooth profiles,
add a config var to disable them.
Change-Id: I04bb7ad4b1235bc37227645f472fdf5b918f6a31
We will fail later anyways, but this change makes it much easier to track
down places where we are inadvertently doing operations that depend on the
flinger.
Change-Id: If38a1a10061a594dba5c220a86b32eec7b5ec901
If you cleared the last usb mode it would fail (and so would setting
it if you started with none). This fixes it to set and unset the
last property correctly.
Change-Id: Ice5be6e57b6ca6b8c9241b0ac62071a3bc72606a
A new switch was introduced in AndroidAtHome to deal with a race
condition between the WiredAccessoryObserver and the HW composer HAL.
When the new switch ("hdmi_audio") is present, we want to pay
attention to it instead of paying attention to the old switch
("hdmi"). This change checks at startup for the presence or absence
of the new switch and uses it if available, otherwise it falls back on
classic behavior.
see change ID I960cfc2f3e8df5342e7248a26fd313fdad2ca322 for the kernel
side changes.
see bug 6023647 for a discussion of the issue.
Change-Id: I009e443f25662e7beb233e892ca71034b05ebfc2
Signed-off-by: John Grossman <johngro@google.com>
The key chord screenshot mechanism introduces significant latency into
processing of volume-key input; enough to be quite noticeable and
annoying on some kinds of device. This patch introduces a new config
resource entry ("config_enableScreenshotChord"), true by default, so
that products on which this functionality is inapplicable can avoid
its runtime overhead.
Bug 6039047
Change-Id: I968ddf9046741da35988310b7893fae2c0369beb
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
