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