IWindowManager now supports two new methods,
freezeRotation() and thawRotation(), that allow a caller to
temporarily stash the device's current rotation as the
default rotation (when no other constraints are present).
The system bar uses this to implement a user-accessible
rotation lock by calling freezeRotation() and then turning
off accelerometer-based display rotation; unless overridden
by an app, the display will continue to appear in the frozen
rotation until the rotation is unlocked by the user (either
via the rotation lock icon in the system bar or by checking
"rotate screen automatically" in Settings).
Bug: 2949639
Change-Id: Icd21c169d1053719590e72401f229424b254622f
Don't be tricky when trying to set the seed for the secure
random number generator. Setting the seed manually eliminates
the internal randomization the SecureRandom class does automatically,
reducing randomness. Just use the default seed, which is designed
to be safe.
Change-Id: I5747c2b3a10cf04e33d2202195951ed5cb82b2fe
Merge commit '04bc807057d1c336a5d1340595b790eee4c5b372'
* commit '04bc807057d1c336a5d1340595b790eee4c5b372':
Allow Bluetooth radio to be toggled in Airplane mode.
Add "bluetooth" to the list of toggleable radios. Because this string
is in the Settings DB, I had to bump the version number. Why is this in
the settings DB anyway, rather than a carrier config option?
I also discovered that the SystemUI package copied the entire contents of
res/values/defaults.xml from SettingsProvider, when I originally tried
to update the unreferenced SystemUI version of the setting. To prevent
future confusion, I removed all of the values from the SystemUI version
of res/values/defaults.xml.
Change-Id: Ib8a75c85b9db5c1963b65538ee2765d5087e67d2
This can be used as a compatibility workaround for host operating systems
without MTP support.
Change-Id: If4f1856206056ca8e40c3ffbfa382f185c413598
Signed-off-by: Mike Lockwood <lockwood@android.com>
Merge commit '603a1f59703109c89ec0fdeceb0f8d28c7cede22'
* commit '603a1f59703109c89ec0fdeceb0f8d28c7cede22':
Fix some bugs in SettingsProvider that I introduced the other day.
Merge commit '384759b1c5e39d0f99fa551a369ae73197ab26c5'
* commit '384759b1c5e39d0f99fa551a369ae73197ab26c5':
Make the default backup configuration "disabled; local transport selected"
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
Merge commit '36c051c717391afe12a1fe8163960286175f2f7e'
* commit '36c051c717391afe12a1fe8163960286175f2f7e':
make android_id random seed depend on time as well as ro.serialno
Merge commit '0fe27cf5bd1407bc7b4eabefaa91ff535582badc' into gingerbread
* commit '0fe27cf5bd1407bc7b4eabefaa91ff535582badc':
make android_id random seed depend on time as well as ro.serialno
We were accidentally stripping both leading and trailing commas
when removing a provider from the enabled provider list.
Signed-off-by: Mike Lockwood <lockwood@android.com>
Merge commit 'feb976e6be3a07dd31b35b35287420bba9ffbbf3' into kraken
* commit 'feb976e6be3a07dd31b35b35287420bba9ffbbf3':
Fix an upgrade bug in SettingsProvider.
Move install location values to secure settings.
Diable attribute for UI. Set default value to auto.
Add command line interface to set install location via pm.
Change-Id: I80e97b3d24845adad7102f40dcbe238f00efa406
Merge commit 'e133177980b908d183ed8fe46cf3ea33405b8bd5' into kraken
* commit 'e133177980b908d183ed8fe46cf3ea33405b8bd5':
Fix for Never not existing in latest timeout values.
unclosed SQLiteStatement objects cause finalizer warnings.
nix them by closing this object in finally block.
Change-Id: Iea86ff169f935bb743aa0c32aa4aeb0cb4fcd4ad
Use constants defined in PackageHelper for user preferences
to install auto, internal, external.
Set default install location to external.
Update settings db version number
Change-Id: Ib5110c9377990e20a48cee923e55898dfddfd1e6
On insert(), check to see if the value is redundant by checking if
it's the same value already in our cache (but without faulting it in
to check). If so, avoid hitting sqlite or spamming all the
notification listeners with such uselessness.
This reportedly is happening a fair bit.
Change-Id: If58feb3ff1d00027dd927e0900087388cbcd72ae
This brings down Settings lookups to 0.5 ms on sholes. (down from
~10.5 ms originally, and ~2.5 ms after the ContentProvider.call()
interface)
Change-Id: Ibde7c3d21e0b0e5714714a2075f314726edfc19d
This permits implementing interfaces which are faster than using
remote Cursors. It then uses it for Settings & SettingProvider, which
together account for ~50% of total ContentProvider event loop stalls
across Froyo dogfooders.
For fetching Settings this looks like it should reduce average
Settings lookup from 10 ms to 0.4 ms on Sholes, once the
SettingsProvider serves most gets from in-memory cache. Currently it
brings the Sholes average down from 10ms to 2.5 ms while still using
SQLite queries on each get.
