Merge commit '02e18d4d4eed949da02fd8aa87801858d99b902a' into gingerbread
* commit '02e18d4d4eed949da02fd8aa87801858d99b902a':
Make the default backup configuration "disabled; local transport selected"
The settings database cache is tiny (or should be tiny) and can be
slurped into memory. Once it's in memory and we know we have it all
we can avoid going to disk at all for keys not in the cache.
This is a big percentage of the StrictMode violations & latency.
Change-Id: I649411be0c40d348f58376ccfb3eda059fd69fbc
By default out of the box, an Android build will have the backup mechanism in
its "disabled" state and pointed to the LocalTransport test transport. We
do not want retail devices built without the Google backend to have backup
enabled out of the box; it would cause them to gradually grind away the
cache partition for no good reason. On those devices with this change,
developers would need to enable backup manually (possibly using the normal
Settings UI; more probably using the 'bmgr' shell tool), but would no longer
also have to manually configure the active transport name.
Device vendors producing Google-enabled products will simply use resource
overlays to configure the default state and transport name for their builds.
When building a product that points to the Google backup transport by default,
the "def_backup_enabled" boolean resource should still be set to 'false' --
the Google backup disclosure activity supplied by GSF will take care of
enabling the backup services if the user opts in to it. (Basically, vendors
will never have to overlay the def_backup_enabled resource -- the default
value of 'false' is correct for any retail device regardless of whether it
can use the Google backup transport.)
In the SDK build, the default transport will remain the local one, but
the default enable state overridden and set to "true". This is the ideal
situation for developers: all aspects of the backup mechanism immediately
operative with no manual configuration needed.
Change-Id: I866f8f627b023b338bc7757e61604e6d8a901a34
Modified lvm reverb wrapper code to expose a preset reverb interface.
Also removed debug log from bundle and reverb wrapper.
Change-Id: If9b95d91e25a6ff834decdfdda34b17df9b46967
* rename setThreadBlockingPolicy to setThreadPolicy (opens the way to
using StrictMode for non-blocking-related things in the future?)
* add allowThreadDiskWrites() and allowThreadDiskReads() to modify the
current policy mask and return the old one. this will allow turning
off part of StrictMode during certain regions of code. (for
instance, writing to disk in Activity onPause...)
Change-Id: Ia1878153713f79299971fdab567fa15b3cb9d56c
We were using a flag so new broadcasts replaced old. If people are expecting
to see all the broadcasts they sometimes would fail.
bug:2892383
Change-Id: I63df17fe8f8c68f59e1ad6297fe93e169b4463b4
and fix the bug of re-assigning connectTime's in SipConnection,
and adding synchronization for SipPhone to be thread-safe,
and set normal audio mode when call not on hold instead of on hold in SipAudioCallImpl,
and fix re-entrance problem in CallManager.setAudioMode() for in-call mode.
Change-Id: I54f39dab052062de1ce141e5358d892d30453a3a
yaffs2 is single-threaded and any disk access during window drawing
(or animation in this case) can cause UI stutters / unresponsiveness
for hundreds of milliseconds.
BUG=2941119
Change-Id: Ifdce8337027ab25d1ea844934fa787ffe68263c4
Merge commit '397c0f5a18281e3880b9359feab683a13d271a03' into gingerbread
* commit '397c0f5a18281e3880b9359feab683a13d271a03':
Doc change: Add table to clarify launch modes and caution against using SingleTask and SingleInstance modes.
Vertical movement requires going over a given threshold to change line.
Makes it easier to move down without changing line, so that one can see the
cursor better. Also simplifies long line selection.
Change-Id: I791da500232c6e510af64c637ed994c5da9a4fea
Merge commit '5a98fef352ed835406fa74a5563eadd9708f7cf9' into gingerbread
* commit '5a98fef352ed835406fa74a5563eadd9708f7cf9':
docs: add dev guide for getting user location