1. Print settings already support managed profile. Follow the UI of that.
ProfileSettingsPreferenceFragment is created to act as the base class
for per-profile setting.
2. Only show browser and dialer default setting in managed profile.
BUG=26707733
Change-Id: I20d00203e14db58ec03638f692dd83a1bd50c59c
When the admin has disabled fingerprint as unlock option, we let the
user know that the admin has disabled that option with a more details
link which will trigger the admin support dialog. And made some small
fixes apart from this.
Change-Id: I01021b952dc6fb29a65d37401a6411a6088d5cef
Update the UX and dig the data usage screen out of a huge whole of
technical debt. Switch every to use Preferences rather than standard
layouts and ListViews.
Split data usage into several fragments, all separated.
DataUsageSummary:
- Shows a summary of the 'default' usage at the top, this will be
the default sim on phones, or wifi if it has it, or ethernet
as last attempt to show something.
- Also has individual categories for each network type that has
data, cell, wifi, and ethernet. Maybe should look into bt though?
DataUsageList:
- Takes a NetworkTemplate as an input, and can only be reached from
the network specific categories in DataUsageSummary
- Shows a graph of current usage for that network and links to
app detail page for any app.
- Has gear link to quick get to billing cycle screen if available
BillingCycleSettings:
- Just a screen with the cycle day and warning/limits separated
out from the data usage.
AppDataUsage:
- App specific data usage details
- May need some UX iteration given lack of clarity in the spec
Bug: 22459566
Change-Id: I0222d8d7ea7b75a9775207a6026ebbdcce8f5e46
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>
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)
When the home screen selected by the user isn't encryption aware, we
still need to put something on the ActivityStack. For now, let's use
an empty activity that knows how to dismiss itself when the
credential-encrypted storage is unlocked; that's enough for the
system to re-resolve the home intent and find the real home screen.
Also follow method refactoring.
Bug: 22358539
Change-Id: Iebc4ad8d2dd62ada079cab03d5765f7631fd4beb
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
Actually call to recovery from ConvertToFBE
Adding credential check
Gray out Convert option when converted
Change-Id: Ic98929ff49733d182b529012e58870156f40679a
This set of changes adds the screen that offers this conversion,
and the plumbing so the option is only available on suitable
devices.
It does not implement the conversion mechanism.
Change-Id: I3c84dd40dfcb0e00dadbab54ba0e56e1ccb11ed8
am: c271a8a00e
* commit 'c271a8a00e2686c371420406a12fd41c4a97e24d':
Further tweak to issue #issue #25371736: Don't include z-ram allocations in Android OS
am: 3b4e4dd91d
* commit '3b4e4dd91d416c93fdc0326e54469ceabb8281ab':
Further tweak to issue #issue #25371736: Don't include z-ram allocations in Android OS
Make sure the duration shown for z-ram is sane (the maximum of the
other process durations of that app).
Change-Id: I62c46b89f927b2c7c16f5c31f6910419b2bdd130
Just distribute them across all of the running apps, by creating
an additional fake "z-ram" process for each of them.
Change-Id: I9b4efe9c7b907779a0ec76cb8652709619e2e686
Also make sure that the 'Clear defaults' action unsets the app's
standing as the default browser, when applicable.
Bug 23751034
Change-Id: I6131b763bfa76ba38d18cad2abbb35caffe789aa
