We now remember whether Wifi was enabled
prior to enabling tethering. This will
allow us to restore Wifi when tethering
is disabled.
Bug: 2537983
Change-Id: Ia530563bd5647856d62cd59b67ae5156de6fd5d9
We need to explicitly disable wifi while enabling
tethering and disable tethering while enabling wifi
Bug: 2539071
Change-Id: I7fda6e4d9d1bb804e81561d52b5f3a982a674b0e
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.
have open file references on the sdcard. We also have to check for apps on sd
that are currently running. Use the new ActivityManager api to get a list of these apps before deciding to show the dialog.
Change-Id: Idb00fcbd0a3f314d75ee1662cb2b10a84569527a
This avoid the main UI glitching when an update happens. Also fix
some problems with how overall memory usage was shown.
Change-Id: Ida415eb07c8671059a24c3be1ebf16910f4b6da2
the current engine that the user has selected when displaying
the list of engines that are available.
Change-Id: I77d35ff1c691fd3e5c967fcf367647d415d2468e
In normal operation, Phone.getLine1Number() returns an empty string if the
device doesn't know its own phone number for some reason. However the
monkey caught a case where it was returning null, which crashed the
Settings -> About Phone -> Status app.
However the javadoc for Phone.getLine1Number() *does* clearly say "May
return null if not available or the SIM is not ready", so the Status app
*should* gracefully handle this.
Now it does. (We display this case as "Unknown", just like if we get an
empty string.)
FWIW I grepped thru the rest of the code base for other uses of
getLine1Number(), and everybody else *does* handle null gracefully except
for one case in apps/Mms, which I'll open a separate bug about.
Bug: 2520977
Change-Id: I173561f903f116dbdc2b7c32b8011b59a9eb29d7
We should really have a separate string here to indicate
this case, but it's pretty late for that sort of thing, so I
left it at the generic "configure dock audio".
We might also want to dim this setting rather than popping
up a "Must dock phone first" dialog if the phone is not
docked.
Bug: 2469862
Change-Id: I4c61f5a50baac55881f5a21e523c370c456f0be8
Had to update the filter settings to accomodate the data scheme
sent with the broadcast.
bug:2504908
Change-Id: Idf07d3b6d408489735c55df5f3310551cf6192f5
This is part 3 of the fix for bug 2364220 "Accessibility improvements for
ending calls".
This change adds a checkbox under "Accessibility settings" to control the
new Settings.Secure.INCALL_POWER_BUTTON_BEHAVIOR value, which allows the
user to specify that the Power button should hang up while in-call
(instead of just turning off the screen.) The checkbox is only shown on
devices that actually have a POWER button.
Yeah, it's a little strange having this under Accessibility (since it's not
that obvious *why* this feature is accessibility-related), but there's no
obvious better place. See discussion in the bug for more info.
Bug: 2364220
Change-Id: I0fd7cf357972519b390575b9c06a4bbe46ff1c9b
