This takses care to add an entry point in Settings->System->Reset
options->Delete private space when private space feature is supported on
the device. Entry point appears both when private space exists and also
when private is not created.
On selecting asks for user authentication and on successful
authentication using device lock shows a dialog asking for
confirmation and calls for deletion private space.
Based on this entrypoint it would not be possible to guess if private
space exists on the device.
Recording link : b/329041740#comment3
Bug: 329041740
Test: atest ResetOptionsDeletePrivateSpaceControllerTest and verified
this doesn't give away existence of private space
Change-Id: I9a5b908e7a3f9edaf609cf7e6a87f9842d689ce6
A security vulnerability was discovered by Android security. b/292548775 Within a short period of time after the device reboot, the user could enter the settings page and factory reset the device. Android Enterprise suggests to add DISALLOW_FACTORY_RESET user restriction to the device.
However, DISALLOW_FACTORY_RESET will be enabled on all Android users, including both the admin user and the demo user. The existing behavior in Android settings is that once the user restriction is set, factory reset button will be greyed out, which makes the factory reset functionality in demo user go away.
In demo user, the factory reset command will be forwarded to the current active device owner. So in this change, we separate the button for admin user and the button for demo user.
In demo user, the button is still visible when the restriction is set.
And in admin user, the button will be greyed out as expected.
Once this change is in, then Pixel Retail Demo could set the user restriction properly and rely on its internal logic to do factory reset. If other applications are trying to do the factory reset, it will be denied by OS.
BUG: 292548775
Change-Id: I9d2d47bb29bc2c1e05058b246908768cd2f95990
Code refactor to hide some UI entries, since there's a BluetoothWiFiPreferenceController
covers some of the work for device without SIM.
Bug: 259611847
Test: local & auto
Change-Id: Ia221663e180c8dabed2a25a927643c992ef8ac89
Over the last few years, there have been a number of
Factory Reset Protection bypass bugs in the SUW flow.
It's unlikely to defense all points from individual apps.
Therefore, we decide to block some critical pages when
user doesn't complete the SUW flow.
Test: Can't open the certain pages in the suw flow.
Fix: 200746457
Bug: 202975040
Fix: 213091525
Fix: 213090835
Fix: 201561699
Fix: 213090827
Fix: 213090875
Change-Id: Ia18f367109df5af7da0a5acad7702898a459d32e
This is an upstreaming change of http://ag/8541963 and
http://ag/10296201 to hide some items from settings search.
This CL also adds javadoc to some settings classes to fix pre-upload
warnings.
Bug: 153704887
Test: Manual. In ARC build, "bluetooth" and "accessibility" no longer shows related settings.
Change-Id: Ic3e9217944251adbea1bdd67baf66d3a9e89583a
- Use SettingsLib Indexable
- Directly use resource id in getPreferenceScreenResId
Bug: 135053028
Test: roboletric
Change-Id: I05f493b55e8b6e2091301e9231ba5615215618e6
- Add function getXmlResourceId, Fragments don't need to write
xml resource id twice.
- Remove getPreferenceControllers from Indexable.java. Because it will
move to SettingsLib later for other apps which don't need this function
Bug: 135053028
Test: robolectric
Change-Id: I1e74519aecdea3dde64a5aea79f08d766dbc0003
This patch focused on fixing compile errors and some runtime errors.
Test: We can't test it now. But we will have an integration test later.
Bug: 110259478
Change-Id: I16c471ddcd0fa1460c665b7f74d86fcace5ee67b
getPreferenceControllers() -> createPreferenceControllers() for the same
reason as in ag/3647936
Bug: 73668763
Test: robotests
Change-Id: I97670a91a2a38d1c844d1b9d37f4222c5e6f45a0
To getPreferenceControllers. "all" is redundant. Then internally, the
old getPreferenceControllers() is renamed to
createPreferenceControllers() to emphasize the controllers are created
from code (versus the ones created from xml).
Bug: 73668763
Test: robotest
Change-Id: Ifec46aefdc2a418031c8e152028b30bdcd396fc7
The implementations have been imported into SettingsLib. Setting's copy
can now be removed, which this change also does.
Test: Manually check battery status, which uses FooterMixin, looks OK.
make RunSettingsLibRobotTests && make RunSettingsRoboTests
&& make RunSettingsGoogleRoboTests
Change-Id: I6539605fdad80d156ff5ff249e68df4a1c412067