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
Framework Tethering now will remove USB interfaces from the available iface list
when UMS is started. Do note when UMS changes though so we can display the correct
strings.
bug:2469818
Change-Id: I5bf1eaea71994cbf9882e10301e88593533651a2
This fixes a bug where the system was defaulting to 8 digits max password length.
The UI is best for N <=12, but works for more. I set the default limit to 16 which is
more than most humans can remember. That also seems to be the practical limit for the small
sample of DevicePolicyManagers I checked.
DevicePolicyManagers can always specify more digits if they really want.
Change-Id: I8637e0c9366800886759424b5a28f48dca15c535
