A new ECM service was introcuded in changeId
I831391e4437b51b3312b5273a2360bd029a3d8ee.
We begin calling it, and update/cleanup method signatures to match.
Note: There are two feature flags:
1. enhancedConfirmationModeApisEnabled - read only, protects the
mainline API.
2. extendEcmToAllSettings - runtime - gates calls to the above APIs.
We use both so we can ramp up in teamfood as needed.
Bug: 297372999
Test: Tested on device
Test: atest SpaPrivilegedLibTests
Test: atest com.android.settings.applications.specialaccess.notificationaccess
Test: atest com.android.settings.datausage
Test: atest PremiumSmsAccessTest
Test: atest RestrictedPreferenceHelperTest
Change-Id: I945ec51df5cd63de548a8ffdd1acc4f09f2301e5
This commit continues the work to make all special app access
permissions ECM restrictable. Some implementation notes:
1. The FilterTouchesSwitchPreference and AppSwitchPrefernce components
are replaced with RestrictedSwitchPreference. afaict this is a
superset - it still filters out obscured touches and shows the app
icon.
2. I'm treating this as mostly a refactoring, and so do not have a
feature flag around most of the changes. Enabling ECM for them /is/
behind the feature flag in RestrictedLockUtilsInternal.
3. app_ops_permissions_details.xml is currently only used by
UsageAccessDetails.
Bug: 297372999
Test: Manually tested on device. Automated tests to follow
Change-Id: I65fe7ec099582de19192a77ad2e41c1558761502
SwitchPreference and SwitchPreferenceCompat are both TwoStatePreference.
Using TwoStatePreference in Java will helps migration in the future.
Bug: 306771414
Test: manual - check Settings pages
Change-Id: I84e1d7b09451106797c2b23d127855c6976678ca
The usage access permission of Settings app could be turned off by
starting the activity with USAGE_ACCESS_SETTINGS. Once the Settings app
loses the usage access permission, it will crash the Apps page which
depends on the usage to show recent apps. And this symptom will persist
even with device reboot.
To fix this vulnerability, we can add a package check in onCreate() to
avoid someone trying to start USAGE_ACCESS_SETTINGS with the Settings
package from third party apps.
Bug: 264260808
Test: Manually verify solution with the repro steps and also test the
normal visiting behavior.
Change-Id: If7cb0880e706369504e432b1f1104d06b1fcfa26
Change-Id: I70871aed763d14a79e474547c77c20a9677af6ff
Bug: 148374455
Test: Manual
Test: Create three packages; 1) only request PACKAGE_USAGE_STATS, 2) only request LOADER_USAGE_STATS, 3) request both
Test: Go to Settings -> Apps & Notifications -> Special app access
Test: See that there is only a single entry for "Usage access"
Test: Under "Usage access", see all three test apps appear
Test: Disable access for each application and verify that only the appop for the declared permisson is flipped using
Test: adb shell cmd appops get <<PACKAGE_NAME>>
Change-Id: I7741a703fd4494832347e51e113adf974cc31d2b
Having consistent import order will reduce chance of merge
conflict between internal and external master
Test: rebuild
Change-Id: I0b1a170967ddcce7f388603fd521f6ed1eeba30b
This CL only changed AlertDialog imports.
So, reviewer can review it easily.
Change-Id: I097bc44394195b14287f4f920c570ac8653f356a
Fixes: 111413092
Test: This CL can't pass Robo test.
Remve below preference in Settings>Apps>Specific app:
Display over apps screen> App display on top permisson
Usage access> App usage preferences
Modify system settings> App modify system settings permission
Change-Id: Ib4128e563b0e2739c16136694ce24182f0da6626
Fixes: 72737995
Test: Manual test
Bug: 30681771
Test: SettingsUnitTests
Refactor visibility logging from InstrumentedFragment into a mixin. And
apply mixin in remaining fragments.
Change-Id: Ibbb59904336254a3e4bb9e8c7d0b36e5a6bc2622
page instead of the top level one
Settings:
Added two activities to handle app-specific Intent when app invoke permission
management UI.
SettingsActivity:
Added two fragment classes to handle app-specific Intent when app invoke permission
management UI.
AndroidManifest.xml:
We handle both Intent to top level settings and app-specific management UI for
app ops protected permissions.
AppStateAppOpsBridge:
Added a new field to PermissionState to keep track of permission declared vs one
that is actually granted during install time.
AppState{Overlay/Usage/WriteSettings}Bridge:
Updated the fields affected by changes in PermissionState.
{DrawOverlay/UsageAccess/WriteSettings}Details:
Disabled the toggling of permission if the app did not declare for the asked
permission.
Change-Id: Ibf63e4d9a4fbf7899a93d2176abb1204c4f75557
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
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
