We add a variable for saving wifi state
to restore after tethering.
Bring up wifi on boot up if the state indicates so.
Bug: 2537983
Change-Id: I9c6548b93df6fcbc0cec1e6b857f7224dc6d1b2c
On keyboardful devices, it is possible to disable the system soft input
method. Something changed in eclair that caused the ime to be re-enabled
on every package manager update (packages added/deleted).
Now keep track of disabled system imes in the settings db and search
in that list before enabling a system IME on package changes.
Every time the user goes to settings to enable/disable imes, the list
is re-created.
Any new system IMEs that may be added via an OTA will get enabled if
they have a different package name.
Fix for http://b/issue?id=2539948
This public API can be called from any thread, so do not use an
AsyncTask. In a separate changelist, the caller now uses an
AsyncTask instead.
Change-Id: I646950964323f8c749f9aa2176226561c6f2b21f
Fiddle with how we go into car mode to try to ensure we get a clean
transition. Also have the system take care of remembering the night
mode setting so it will stay at what you want.
Change-Id: Icb94fdd961c7a192f7707ec71544485a1ea12455
Snoozing alarms was causing a leapfrog effect which would drop the
alert in the middle because of PendingIntent. By making each intent
unique to a given time this will no longer occur.
Change-Id: I6ca6821f7f8879a299775f4fca4e2ad0de55f1bc
Fix for http://b/issue?id=2511581
Also call delete instead of deleteHistoryWhere, since we are only
considering non bookmarks anyway.
Change-Id: I00c052db3d27d61592688e7a160e721d5f82b210
Shelling out to logcat from the system server makes me queasy,
so this is turned off by default -- it must be enabled individually
for each error type (system_app_anr, etc) via a secure settings
value (which I plan to poke into from gservices for internal use).
Even when enabled, it happens in a side thread, unless the system
server is about to die anyway (system server restart).
Change-Id: Id6d88bcd78d3625f0364a5fe9c771046601a5a14
This is part 1 of the fix for bug 2364220 "Accessibility improvements for
ending calls". This change adds a new (hidden) constant
Settings.Secure.INCALL_POWER_BUTTON_BEHAVIOR, for a setting that controls
whether the Power button hangs up the current call, or just turns off the
screen.
Bug: 2364220
Change-Id: I14d4a89b27e99cac51dc16826d217072d999b2d6
Add a new column to both the pdu and sms tables. This change just adds
the column definitions. Bug 2505620
Change-Id: I34b2794566a2900932ae34bdded4ed361d503d07
Fix issue #2493497: Stuck in the Emergency dialer - Home/Back keys doesn't work
This was another case of not updating the window focus when needed, this time
when the lock screen was hidden.
Also re-arrange the layout/animate flow to address issues where you would see
a flicker of whatever was behind the lock screen when showing a new activity that
hides the lock screen. This was because we were deciding to hide the lock screen
during the layout phase, which meant we had to do it without considering whether
it had drawn. So we could hide the lock screen before the window is shown for the
first time after being drawn. Now we can do this in the policy during animate, so
we can wait until the window is drawn and actually being shown.
The flow in perform layout is thus significantly changed, where the layout and
animate loops are both under the same repeating loop. The actual flow from this
should be the same, but it now allows the policy to request a new layout after
the animation loop is done. This actually cleans up a number of things in this
code as the complexity has increased.
Finally this includes a change to the ui mode manager when switching modes, to do
the resource configuration switch at a different time. This makes transitions
between modes much cleaner (though not yet perfect).
Change-Id: I5d9e75c1e79df1106108dd522f8ffed6058ef82b
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.
The method for finding matching URLs is taken from Bookmarks.java in
the Browser package. When looking to see if the URL is already in
the database, include versions which have/don't have "http" as well
as "www."
Part of fix for http://b/issue?id=2442391
* This is being used as a discretionary column by Exchange calendar
sync, so rename to avoid association with old usage
Change-Id: I544e285fa04d252c945c1953b57ef67da0e588ae
In earlier versions of Android, "vibrate mode" (in which
only alarms and media produce sound, but notifications may
operate the vibe motor) was only accessible by adjusting the
ringer volume (via the device's volume rocker) down until
the "vibrate" icon appeared (between the lowest ring volume
and silent mode).
Many users prefer that "silent mode" always allow vibration.
Others prefer Android's historical behavior, in which silent
mode stops the vibes as well.
To accommodate these two distinct usage patterns, we now
allow the user to decide whether vibration is allowed in
"silent mode", a user interface abstraction that now spans
both AudioManager.RINGER_MODE_VIBRATE and
AudioManager.RINGER_MODE_SILENT.
To minimize API impact (and therefore maximize backward
compatibility), RINGER_MODE_VIBRATE and RINGER_MODE_SILENT
remain unchanged. What has changed is what happens when the
user activates silent mode, either via Settings,
GlobalActions (longpress on power), volume rocker, or the
keyguard tab. In essence, there is now only one "silent"
position in these controls, and whether RINGER_MODE_VIBRATE
or RINGER_MODE_SILENT is actually set on the AudioService is
determined by a new one-off setting
(System.VIBRATE_IN_SILENT). This new setting isn't meant to
be a long-term API, however: in the future we hope to
replace and extend this design with a much more
sophisticated set of systemwide feedback profiles. ETA TBD.
Related changes:
* I09ad7d69 (GlobalActions and keyguard)
* I22ba7bcf (Settings app)
Bug: 2457183
Change-Id: I14cf91b0910261ffdfd1bf302423f41ec747d057
Added in this CL:
Power sounds enabled
Dock sound enabled
Lock/unlock sounds enabled
Auto-restore app data on install
Change-Id: Ie1c3215e926282e7cac5b82cd6196636049f7f85
