- Don't include info link if just came from app info page
- include back button on app info page when launched from header
Bug: 22203029
Change-Id: I737332a487c41e0a93d161b55659700a1f936844
Overall, fixed the detection of the state of permission in the corresponding UX
to be more accurate. Also ensured that apps can actually launch the summary UX
through a custom intent.
AndroidManifest:
Adds the proper intent-filter so that apps can launch the Settings page using
intent.
strings:
Made changes to strings so that wordings are uniform everywhere and raised the
char limit due to requests from translators.
Change-Id: Ia03403641ad53bd1a33b84dae6db1739cfcf9d60
explicit toggle to be enabled through Settings via Apps -> Advanced Apps.
Added new and refactored an old xml to define the UX for two new Preferences
in Advanced Settings. Modified the existing AdvancedAppSettings to add
control flow for two new settings. Also enriched ManageApplications to
handle these cases. Added additional strings in xml/values/strings.xml
to support these settings. Also defined new classes to handle these the
toggle of these permissions per app.
Refactored codes from AppStateUsageBridge to a generic AppStateAppOpsBridge so
that future usages related to AppOps can inherit from this class.
Change-Id: I43b81282a063e05844c7805556a6d05cfc02bcdb
The user's preferences were not queried on the app listing, making it
look like an app would open links even after the user disabled app
links for the app.
Bug: 21093152
Change-Id: I133ff229bb5e289ebec8df06924936fb3177f095
Allow apps to be enabled as link handlers for their accepted domains
even when they are not the "official" apps for those domains.
Also clean up a bunch of inconsistent/wrong state reporting in the UI.
Bug 22069429
Change-Id: Ic3b2bcc476dfc30085d3df7412b02bdc5d53df6d
Make all app lists (or at least all current app lists) use the same
base layout for icon, label, and sizing/padding. This way they
should look the same.
Bug: 21727125
Bug: 21726922
Bug: 21853632
Change-Id: I3cffadb9e7b5184d4209deacd4ea70ec1d4f71b4
When launching the battery whitelist for a particular app, we now
default to the app being asked to enable adding to the whitelist, and
dismissing the dialog will dismiss the entire whitelist UI.
You can now launch the whitelist without specifying an app to just
get the regular UI.
Change-Id: Idf3840b8a30febe71fbd600969c257d72809643f
Also take InterestingConfigChanges along for the ride
and delete unused AppPermissionSettings
b/21328967
Change-Id: I4d0c1a27054845a54cf68e95a92024d2e46f636e
- Handle a backup URI, so that if the specified URI is not available,
another can be used.
- Add some data to help intents when they are intent URIs
- Fill in the context with a classname when it isn't present
Bug: 15475009
Change-Id: I7050fa61121901929e650b20bd7a0ae21e8ba207
Don't rebuild the app list until the entry load is complete to avoid
having a slowly populating list shown to the user.
Bug: 21086054
Change-Id: I801ab292fdbf6801c1b9c8f957336660810da5f6
Mostly just string updates.
Also fix crash in power details.
Bug: 19991702
Bug: 21027488
Bug: 21063077
Change-Id: I5a5e382a20ffaecd9eb16454906c985cc1510572
This info button is shown on the header of all app detail pages.
This button is hidden when coming from app info, to avoid allowing
users to go in circles.
Since app notification details had a settings button where the new
info button goes, the app notification settings will move down to
be a preference (this matches the usage access screen UX).
Also fix a bug in launching app notification settings for managed
profiles.
Bug: 20633669
Change-Id: Idbb4f7c3326b4c6b0a19559b722ee0406eaba6c0
Use SettingsPreferenceFragment's method for pinned headers where
possible, and add a frame within the fragment for them to live in
otherwise so that this view doesn't end up on the activity.
Bug: 20886475
Change-Id: I985eb1497744ea50bfabed862e5088eb89df5b61
- Strings not final!
- New UX for power usage details (more preferency)
- Add high power apps list shows on/off and screen to
change (when possible)
- Link from power usage summary to high power list
- Link from advanced apps to high power list
Bug: 19991702
Change-Id: I97c927ed82d3b89041e4429b427508545763d66c
Entries in the app list should not be disabled, instead we should
be filtering for only items the user can modify.
Bug: 20210219
Change-Id: Ida298a9ba16c1201ac238b85f299bdc7b0ae7a1d
Now uses ManageApplications base, and has a details screen which has
a switch and a link to optional app settings.
Bug: 20290386
Change-Id: If32ce8d82e55f3908644c575925b3f6506a68e6e
We now allow moving packages between all possible candidate volumes,
as determined by the framework. Moving now jumps through wizard to
help user understand what's going on.
Bug: 19993667
Change-Id: I5416ed2865f400b1d718c68a3f0e033080fefa0e
Allow help uris to be either an intent uri or as uri (as they were
before). Also add a default help uri, and specific helps for several
screens.
Bug: 15475009
Change-Id: Iff982892973f01d32ff61ea88d4844e9a7153500
Instead move the functionality back into overflow menu as show/hide
system apps. Also move the reset app preferences from advanced to
the overflow menu.
Bug: 20210160
Change-Id: Ied573e1f7dfc438b06642ee2af8f11868130ba3b
Also add loading screen to manage permissions as this can take a
long time to load in some circumstances. Build loading screens into
Utils and SettingsPreferenceFragment so that it can be easily used
other places in the future.
Change-Id: I7febd06695487e02ced793a9fd418051b5f0eab8
UX fixes
- make the ManageApplications list to be able to handle some disable items
- add domain list for App that are not verified
Change-Id: Ib37c6f3f3dd1d1cdc17db434967f583cc89e068c
