This makes SystemUserHomeActivity, which also has a low priority,
works properly for system user.
Bug: 26358655
Change-Id: If07b39ac5a7015805ac22a968b3d704aaad80012
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
Modify the back stack and result code propagation in the screen lock
scenarios.
- EncryptionInterstitial now propagates the result of ChooseLock*
request instead of always returning RESULT_OK.
- ChooseLockGeneric now treats CHOOSE_LOCK_REQUEST and
ENABLE_ENCRYPTION_REQUEST the same (since encryption can be a proxy
for ChooseLock*). This means ChooseLockGeneric will now stay on
back stack when going back from ChooseLock*, just like the case
(indirectly) through EncryptionInterstitial.
Bug: 26177240
Change-Id: Id7f1256dcbff00d552a3e7db60c285f53f1e63e6
Add support in the Confirm Credentials flow to read an Intent extra
and fire it when authentication succeeds.
This is part of the Separate Work Challenge feature.
Change-Id: I52c203735fa9b53fd2f7df971824747eeb930f36
