The intent and permission were both over-verbose. Renamed them to be
more succint.
Bug: 74763823
Test: Manually check; sending an Intent with package:// scheme works, if
originated from app of same cert.
Change-Id: I789b07d4a7c0714c021b94aced39c8e4476c8ed0
In 534d732e9f274ad3f3e0637b9da963f889309afb, we are restricting privileged apps from silently becoming
Device Admins. Privileged apps can now call the following existing Device Admin APIs provided they have the correct permissions:
1. DevicePolicyManager#resetPassword -> Guarded by android.permission.RESET_PASSWORD
2. DevicePolicyManager#lockNow -> Guarded by android.permission.LOCK_DEVICE
The following existing Device Admin APIs already have alternatives hence no change required:
3. DevicePolicyManager#wipeData -> Send ACTION_FACTORY_RESET broadcast.
Guarded by android.permission.MASTER_CLEAR
4. DevicePolicyManager#setKeyguardDisabledFeatures -> Write '0' to LOCK_SCREEN_ALLOW_PRIVATE_NOTIFICATIONS setting
Guarded by WRITE_SECURE_SETTINGS
Bug: 111153365
Bug: 112601004
Test: Manually tested with dev privileged app
Change-Id: Ia4e1ce9b81756e7f84ed0aa22d97e0b968cd8d89
a69e367808 restricted
CAPTURE_SECURE_VIDEO_OUTPUT to signature only. This breaks
casting premium content from Play Apps & Movies and YouTube
app.
Revert the restriction for now while we figure out the right
thing to do.
BUG: 114183892
BUG: 111131054
Test: Tested by mirroring the device to chromecast and verified
playing premium content on Play Movies & TV app and YouTube
works correctly.
Change-Id: Ifb247c17be924655d7fc95b7e957f9822254d363
This CL moves InputMethodManagerService (IMMS)
from com.android.server
to com.android.server.inputmethod
so that we can mechanically factor out inner classes from IMMS to
separate package private classes.
This is purely a mechanical refactoring of an implementation detail.
There should be no observable behavior difference.
Fix: 114660660
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Test: atest FrameworksCoreTests:com.android.internal.inputmethod
Change-Id: I023d8f2863601ee54f304988117d8ea750770f70
This reverts commit 3f523d2bd3.
Reason for revert: Design changed, use name from multiple user instead of emergency info name, so revert this CL.
Change-Id: Ib091c18b90c1f919906602599e00364746d2160b
Restricting CAPTURE_VIDEO_OUTPUT permission in ag/4779804 preents the system from binding to RemoteDisplayProviders.
This breaks a legitimate use case of casting a device from Settings.
We temporarily soft revert the change pending a better solution.
Bug: 113371538
Test: Manually tested by casting to a Chrome Cast device.
Change-Id: If8f7fd775998d1b7bcdf9f72fe92cb86845f2044
The change introduces the following:
- BiometricPrompt communicatates with BiometricPromptService (new)
system service. The service does the decision making for which
biometric modality to use.
- As a result, a lot of logic is moved from <Biometric>Manager
to BiometricPrompt. FingerprintManager now does not care about
BiometricPrompt logic anymore (reverts several P changes).
Face, and all future <Biometric>Service interfaces must be protected by
the signature-only MANAGE_BIOMETRIC permission. Settings, SystemUI, and
BiometricPromptService are their only clients.
Bug: 72825012
Test: BiometricPromptDemo works
Test: Keyguard works
Test: Settings works
Change-Id: I2b7d6eff81bc07950202c50e592d733032523bf0
We want to restrict screen reading permissions
to signature only so only the platform and
apps signed with the platform key can access
the device screen.
Add @removed and @hide to the permission so that it's
not in the docs any more without breaking any existing
apps referring to the permissions.
Bug: 111131054
Test: atest PermissionsHostTest
Test: make & verified generated file
out/target/common/obj/PACKAGING/hiddenapi-light-greylist.txt
contains CAPTURE_VIDEO_OUTPUT and
CAPTURE_SECURE_VIDEO_OUTPUT.
Change-Id: I451fec868e5e079dc7204fb097191a565627f939
We want to restrict screen reading permissions
to signature only so only the platform and
apps signed with the platform key can access
the device screen.
Add @removed and @hide to the permission so that it's
not in the docs any more without breaking any existing
apps referring to the permissions.
Bug: 111131054
Test: manually tested screenshot & bugreport
Test: atest PermissionsHostTest
Test: make & verified generated file
out/target/common/obj/PACKAGING/hiddenapi-light-greylist.txt
contains READ_FRAME_BUFFER
Change-Id: I8294aff965e889335a495ab792f893957d39ec5d
Change-Id: I8294aff965e889335a495ab792f893957d39ec5d
Bug: 74244324
Test: ./frameworks/base/wifi/tests/runtests.sh
Test: live test with Passpoint R2 service provider AP
Change-Id: Iba35ab14b6b5925d2ef0435af9e94f97d0d9fa1d
Signed-off-by: Ecco Park <eccopark@google.com>
We now have separate permissions that correspond to the various
MediaStore tables:
-- READ/WRITE_MEDIA_AUDIO
-- READ/WRITE_MEDIA_VIDEO
-- READ/WRITE_MEDIA_IMAGES
From a product point-of-view, Images and Videos will being treated as
a single permission group of "Visual" media in Q. We're also defining
two other special permissions:
-- ACCESS_MEDIA_LOCATION: indicating that the app can see any
geographic location related metadata associated with media, such
as being stored in the EXIF data. We're willing to grant this under
the unbrella of the larger "Visual" runtime permission group, but we
still want apps to request it for full disclosure of their intent.
-- WRITE_OBB: can be held by app stores that need to deliver OBB
files into app-specific sandboxes to keep legacy apps working.
Test: manual
Bug: 111801780, 110228267, 111789719, 111892833
Change-Id: If28247efdd7ac185ad3c6cbceda2e6346c26d032
1) Use @TestApis for verify AM related functions to replace using command.
2) Remove "development" protection level for some @TestApis permissions.
Bug: 77988683
Bug: 80415658
Test: atest CtsActivityManagerDeviceTestCases
Change-Id: I4bb10b45a2269c9e871f38f219d3e92cb45eeb9d
- Added the new android.permission.WRITE_SETTINGS_HOMEPAGE_DATA
- Updated AndroidManifest.xml
- Added this permission as @hide
Change-Id: I44836dcd9e24d6ec6e15179dfc2dbde59c275553
Fixes: 111777015
Test: compilation
Added protected-broadcast for 4 actions that will be used by Car
service:
* com.android.server.jobscheduler.GARAGE_MODE_ON
* com.android.server.jobscheduler.GARAGE_MODE_OFF
* com.android.server.jobscheduler.FORCE_IDLE
* com.android.server.jobscheduler.UNFORCE_IDLE
Test: WIP
Bug: 111552186
Change-Id: Ifa6729db38f32479f06e814a713ba9e2b419f88f
This splits the
- review permissions
- individually control permissions
- consent to manage wireleess (wifi + bluetooth)
properties.
Almost all code cares only for the first and it is now always true.
Hence a lot of code can be simplified.
Bug: 110431654
Test: atest PermissionsHostTest
started pre-M app
Change-Id: I733cd476ccd0bf5eaa59e9a9506db34f57c6baee
Add signature or system permission
"android.permission.MODIFY_DEFAULT_AUDIO_EFFECTS" for AudioEffect APIs
allowing system services and applications to modify what effects get
automatically attached to streams/sources/devices of various types.
This permission is hidden for now, since this API is not yet approved
for mainline Android.
Bug: 67964202, 70300942
Test: None
Change-Id: I51b4e3a939e16221633448f646e5129e1a62dd23
Applying this mechanism for system carrier apps to make visibility
reasonable from the user's perspective. In other words, before
hidden system apps have been installed, they wouldn't be listed
via APIs in PackageManager which are used at all apps list and
search in Settings and so on.
Test: atest CarrierAppUtilsTest
Test: atest PackageManagerTest
Test: cts DeviceOwnerTest
Test: gts ManagedProfileProvisioningHostsideTest
Bug: 74068582
Change-Id: I1f23aba589b98351a1871a44a3058b67c416f351
This change is cherry-picked and rebased from AOSP
https://android-review.googlesource.com/c/platform/frameworks/base/+/660242
Add face recognition as an identification method, following fingerprint
design. Unlike fingerprint, only one face template can be enrolled per
user, and a vendor message is passed from the HAL all the way to the
client callback to allow GUI indication about the enrolled face
templates.
Add FaceAuthenticationManager and FaceService.
Add face authentication capability to TrustManager and Keyguard.
Modify TrustManager and KeyguardUpdateMonitorCallback fingerprint code
to support generic biometric method to eliminate duplications.
Add BiometricSourceType enum to keep track of the specific biometric
method.
Test: biometric authentication still works on the device
Fixes: 110385761
Change-Id: I5d04fe69a112c13d3ef7330b9c08c146e36c5335
Signed-off-by: Gilad Bretter <gilad.bretter@intel.com>
Applying this mechanism for system carrier apps to make visibility
reasonable from the user's perspective. In other words, before
hidden system apps have been installed, they wouldn't be listed
via APIs in PackageManager which are used at all apps list and
search in Settings and so on.
Test: atest CarrierAppUtilsTest
Test: atest PackageManagerTest
Test: cts DeviceOwnerTest
Test: gts ManagedProfileProvisioningHostsideTest
Bug: 74068582
Change-Id: I1f23aba589b98351a1871a44a3058b67c416f351
Define com.android.emergency.permission.READ_EMERGENCY_INFO_NAME permission for an application to read emergency info name.
Test: Build pass.
Bug: 80406149
Change-Id: I85ec6cc857efcc06e95dac53ab293798f97e4e4f
Added a callout and a message that more strongly discourages use of
the UNINSTALL_SHORTCUT permission.
Test: make ds-docs -j16
Bug: 72864896
Change-Id: Iacb7a1718c4688e9061bdfd3b50b7afc8f170abb
Added a callout and a message that more strongly discourages use of
the UNINSTALL_SHORTCUT permission.
Test: make ds-docs -j16
Bug: 72864896
Change-Id: Iacb7a1718c4688e9061bdfd3b50b7afc8f170abb
Some permissions are getting split into foreground and background
variants. If an app only has the foreground version it can only access
the protected resource while the user is using it. Once the background
permission is added to the foreground permission the app can always
access the resource protected by the permission.
- Only having the background permission does grant anything.
- Mutliple foreground permission can share a single background permission,
but a foreground permission can not have multiple background
permissions.
- As the implementation of background permissions is based on AppOps
only the system can declare such foreground/background permissions
- A CTS test enforce that the background is in the same group as the
matching foreground permission.
Bug: 78788390
Test: Checked declared permission after boot and found new attributes
Change-Id: Ica7ba77b24345607c7467c41c982a58c39199024
Add a new MANAGE_IPSEC_TUNNELS permission and
protect all IPsec Tunnel mode APIs with it.
This permission is only granted to the system or
through an AppOp.
Bug: 66955045
Test: compilation
Merged-In: I0f618373b500c493ef2211bece681f74652a1833
Change-Id: I0f618373b500c493ef2211bece681f74652a1833
(cherry picked from commit 159788455c)
Work on issue #109754053: Implement tri-state location in platform
- New background location permission
- New (temporary?) API level for compatibility with old apps
None of this is exposed yet as a public API, that will be
done in the future.
Bug: 109754053
Test: atest FrameworksServicesTests:AppOpsServiceTest
Test: atest CtsPermissionTestCases:AppOpsTest
Change-Id: I986dc871b9e8ed3bf592d2546eadaefb4fefe099
