This reverts commit 91e3f72569.
Will wait until related commit is in to submit this.
Bug: 13756871
Change-Id: I34642998adb71f44de1e529cc214ac4f921932ed
This screen was blocked from appearing in the main Settings list, but
search now exposes it.
Disable content on the Users screen if multiple users are not supported
on the device. This is a temporary fix until Settings search does the
right thing.
Bug: 13631986
Change-Id: Icc61d3e9ce4e405d0cf8841af538216be59fac26
- get rid of PreferenceActivity as much as we can and use fragments instead
- add Drawer widget
- add Dashboard high level entry into the Drawer (but this is work in progress and would be done in another CL)
- add bypass of fragment's Header validation when launched from the Drawer but *force* validation if external
call thru an Intent
Be aware that WifiPickerActivity should remain for now a PreferenceActivity. It is used by SetupWizard and should
not trigger running the SettingsActivity's header building code. SetupWizard is a Home during the provisionnig process
and then deactivate itself as a Home but would make the Home header to appear in the Drawer (because momentarily we
would have two Home).
Also, verified that:
- the WiFi settings still work when called from SetupWizard
- when you have multiple Launchers, the Home header will appear in the list of Headers in the Drawer
Change-Id: I407a5e0fdd843ad7615d3d511c416a44e3d97c90
When resuming the restricted user fragment, make sure that the user still
exists, as it may have been deleted by the restricted user.
Bug: 11010340
Change-Id: I3360dbc42586c5bb28013844f8c788e641ad8b6a
Due to the new file picker UI and incorrect assumptions of access to sd card,
have to use content provider Uris instead of file paths.
Also makes the cropping robust in the event of not having a cropping intent
on the platform.
This should make the code play well with third party image
and camera apps as well.
Bug: 10666584
Change-Id: Ie8d834fe7aac96bc14829a7be084512a15ef4001
- Reprompt for pin after screen has been locked and unlocked.
- For protected preferences, store the Preference and continue if pin entry is successful.
- Protect whole UserSettings and DevelopmentSettings pages.
Bug: 10543207
Change-Id: If1d4b31ca94a8cfc103625b74385bcd0bdd3d88b
Instead of showing a separate entry for launching custom restrictions,
launch it directly when clicking on the settings icon.
Bug: 10388399
Change-Id: I327d6d4c2b9840ce5ba140746568c5561a1a8936
This is to make sure that apps that were disabled for some reason
such as inappropriateness for a locale or for a specific device, don't
show up as available to enable for a restricted profile.
But in the case that the app was already enabled for the target profile,
show it in the list so that it can be disabled if necessary.
Bug: 10229133
Change-Id: I3c19edb7364cea42d95b619781e0326543b9a1cf
When these screens are locked down with user restrictions,
it should prompt the user for the restrictions pin before allowing
access to the settings screen.
Change-Id: Iadbb087da2d9470b855ea0bea89f2da1ffb9e854
Also don't show actual Restrictions content if the fragment was launched
through a different entry point.
Change-Id: I70cb76ca6f68a382e68219053e6f69e7f1fa0150
Use usermanager to clear restrictions, as it needs to do a bunch of
book keeping.
Apply PIN restriction to master clear button.
Changing existing PIN now includes verifying the PIN, so it doesn't
need to be cleared here in Settings.
Removed automatic persisting of restrictions on receiving them unless
it is a restricted profile.
Make apps that are signed with platform certs immutable and ON.
Change-Id: Iffd1bf2eb0d18202fb66ddcf80668baa8e6b84ed
New restrictions panel for restricting list of available apps for the user.
Apps that support restrictions can also be configured here.
Restrictions screen is PIN protected and will ask you to create a PIN the
first time you use it.
Change-Id: I7a5267df4272521ad80e6a8b6a18932d07179eb8
When a system app doesn't have any UI, it wasn't being considered for
opt-out. Check for all system apps that want to opt-out and mark them
for uninstallation.
Bug: 8908632
Change-Id: Iad7ccbe544cc7c7ebf73f430fbab8d295eb40219
User shouldn't have to go tap on the settings icon for an app that is ON by default
in a restricted profile. This way apps can write some defaults to the restricted
profile when it is created.
The app entry is also automatically removed from the list if there are no visible
restrictions.
Bug: 9074051
Also fix an incorrect dialog label. Bug: 9068877
Change-Id: I2a7ddc31fe695f58611d2ba36a8bf541b7817b10
When adding color filters to an app icon in User Settings, don't
modify the original drawable state. Get a mutable drawable.
Bug: 9054675
Change-Id: I6ea374cb801abef3f5b597fda2e84b4e67cfa9d0
Save any changes that weren't committed yet, but don't restore
earlier cancelled changes.
Bug: 9008014
Change-Id: I8faacc42a3600d1338ddedb1b59f7307903743b4
Bug: 8735493
If there's no screen lock, prompt to take the user to set a lock.
On return, check if user set the screen lock. If so, add the restricted
profile, otherwise don't add it.
Fix a small layout issue: Bug: 8721209
Change-Id: I2a18fea50a1d810d6a7fa82038b460ca4e03d5a0
Bug: 8736733
Put the summary "Restricted profile" under the user name in app restrictions panel.
Bug: 8736734
Change-Id: I6b724bd10a9246eb57831bffb737a48c01e0c285
Delaying applying the states till onPause() sometimes results in the apps
disappearing slowly as the new user is booting up, causing failed queued up
broadcasts that result in crash dialogs. This happens mainly when the user
switch is initiated via QuickSettings->LockScreen->Switch while the App
restrictions screen is still showing. The onPause() gets called when
SetupWizard actually takes focus, which is quite late, as boot completed
and other events have already been queued.
Apply the initial toggles right away and apply any user changes when primary
is going to background, or onPause(), whichever comes first.
Bug: 8685927
Also ensure that apps with restrictions get a chance to persist their defaults
as soon as they are toggled on. The user may never actually click on the settings
icon for the app (which was the only way they were getting persisted before).
Some new strings for an upcoming change.
Change-Id: I96f453d066a91c6b15eafe9a6ce3f42d98bf5e33
Add default IMEs to an exclusion set so that we don't include them in the
list of toggleable system apps that we show the user.
Bug: 8724246
Unrevert the change to include disabled apps, as the above change fixes the
reason for the revert.
Bug: 8713202
Change-Id: Ifced841ad3bfbde33d2403356216dd1749b7fa9a
This is breaking restricted profiles because the Google Keyboard suddenly
shows up in the list as disabled and InputMethodManagerService crashes
if the only available keyboard is not installed for the profile.
This reverts commit 90dcd7469b
Change-Id: Idd7c4f0f93a973b777889865e80c53caad759a63
If we don't show disabled system apps for toggling, they'll end up
being automatically included in the restricted profile.
Make sure that we also list disabled apps.
Bug: 8713202
Change-Id: I8f2facf496f669dfe963cdabf3d29d393097a80b
CircleFramedDrawable was trying to draw itself as big as the hosting view by
looking at the canvas size. However, due to inconsistent API behavior for the
cases with and without hardware acceleration the canvas size returns the
size of clipped canvas or the size of the entire canvas, respectively. While
we should fix the inconsistent API behavior, it is not correct for a lower
level component to know about the higher level one, i.e. a drawable trying
to infer the size of the hosting view. The hosting view should set the size
of the drawable. This change removes the dependency on the host view size and
if one wants to enlarge the drawable, he/she should just set the scale.
bug:8671059
Change-Id: Idc572da7dff60fd10cb37d3c3eca27aac2c0a21f
