A session keeps in ApplicationsState list. The fragment don't release
the session when it is destroyed. The cause of out of memory is that the
session list is increased, but it can't be released.
Change-Id: I23635610c9fdfb8a3423299a91cf9b11cb5cdb65
Signed-off-by: daqiangx <daqiangx.li@intel.com>
This makes SystemUserHomeActivity, which also has a low priority,
works properly for system user.
Bug: 26358655
Change-Id: If07b39ac5a7015805ac22a968b3d704aaad80012
File.java will return the total size in bytes of the partition
containing the path, and if the path does not exist,
it will return 0.
Change-Id: I134d4ec787b475e38bb37b4386bafcc419971c1e
BluetoothDiscoverableTimeoutReceiver cannot receive
DISCOVERABLE_TIMEOUT intent because receiver name attribute
was incorrect.
BluetoothDiscoverableTimeoutReceiver has been moved to
frameworks/base/packages/SettingsLib/.../bluetooth
from packages/apps/Settings/.../bluetooth/.
Change-Id: I52bb32b2e206f5ed85207d6908e3ab39cbcd12cc
Suppress the activity transition when finishing so that only the
dialog's animation will be played.
Bug: 25796672
Change-Id: I0c472313608aa46f780ce2fdb79224c0ad3a4dad
The privilege for an app to write to the system settings is protected
by an app-op signature permission. App-op permissions are special: if
the app-op is deny/allow we deny/allow write access; if the app-op is
default holding the permission determies write access. The settings
code assumes that CHANGE_NETWORK_STATE is an app op permission
(system|appop) while it is a normal permission which any app gets by
declaring it used in the manifest.
The side effect is that the state of the toggle in the UI for write
system settings will initially be in the wrong state if the app uses
both WRITE_SETTINGS and CHANGE_NETWORK_STATE. However, the code in
the public API an app uses to check write settings access would return
the opposite since it checks the WRITE_SETTINGS permission and its
app op. Hence, if an app requires write settings to start the user
will see in the settings UI it has access but the app will not have
access, so the app would prompt the user to allow write settings.
The non-obvious fix is for the user to toggle the setting off and on
to get the app op in the right state and be able to launch the app.
bug:25843134
Change-Id: I3d726a66c7f9857bc7dbd5946fdbb8f340c6eb4d
(cherry picked from commit 356fb2d10d)
Add a UsbDisconnectedReceiver to listen usb state event, and hide
the usb mode chooser dialog if usb disconnected.
Change-Id: I871f56cb5a310e20950926180d9747dd9fad9754
Signed-off-by: Du, Changbin <changbin.du@intel.com>
Signed-off-by: Zhiquan Liu <zhiquan.liu@intel.com>
Moved the area info handler from CellBroadcastReceiver to
CellBroadcastAreaInfoReceiver.
bug: 25628456
Change-Id: I2c7c6bb83245fcb6d9cc7b5dce7496e906160bab
We are now using the same configuration as WifiSettingsActivity,
which also uses the same configChanges parameters. This keeps the
Setup Wizard instantiation of WifiDialog and the settings instantiation
closer together.
bug:26220180
Change-Id: I05e692d6cb81d3765a3de4ccd6c074deffada72e
* Normal Report: the new, enhanced option is more user-friendly (it
shows a system notification with the progress, allow user to cancel,
etc...), at the cost of consuming more resources. When this option is
selected, the bugreport will be delayed 2 seconds so user can dismiss
the Settings app before a screenshot is taken.
* Emergency Report: a lighter approach that is less intrusive and
should be use when the phone is unresponsive or too slow.
BUG: 26034608
BUG: 11665244
Change-Id: If9c0242a163c8c33adecfc8a65af561e839bab8d
When starting a Guest user for the first time, it can take quite
awhile before the Home app enables itself. So if we're unlocked
and no other Home app is around, chill for 500ms and see if someone
showed up.
Bug: 26267450
Change-Id: I3c4e01ae3681c650ea90b20ffc21835ae264b5e9
The picker in frameworks/base does the simpler job: when called it
returns one locale only, no knowledge of locale lists.
The previous com.android.internal.app.LocalePicker shows a list of
locales based on the localised resources available.
The replacement (LocalePickerWithRegion) shows a more complete list
(a curated subset of all the ICU locales, but still pretty big).
Because of the length of the list the LocalePickerWithRegion splits the
selection in two: you first select the language, and then the region
(where that language is used).
If you need to select one of the locales completely supported by the
system (that have translated UI), continue to use
com.android.internal.app.LocalePicker
They should be compatible: they show some UI and end up selecting a
locale.
Beyond the UI differences, LocalePickerWithRegion will return more
"granular" locales (tens of French, or Spanish, or English locale
variants).
Bug: 25800339
Change-Id: I0371d82302b462b1a633c149df08a39b6d508f58
