Add a new internal permission required to disable hidden API checks using
"am instrument". Grant this permission to the shell.
Test: $ adb shell am instrument --no-hidden-api-checks mypackage/.MainInstrumentation
Bug: 64382372
Change-Id: I193dba412560f17810ad0c67c733a1eec15fa7b7
- Fix issue with testFinishPipActivityWithTaskOverlay failing due to
new permission check in the system
Bug: 71716434
Test: atest CtsActivityManagerDeviceTestCases:ActivityManagerPinnedStackTests#testFinishPipActivityWithTaskOverlay
Change-Id: Ifbcd6c182d928f5aa5372d2db9fa71a142dc8474
Add a new platform-only permission for being able to change
app ops mode, so nothing outside of the platform can do this.
Bug: 62342672
Test: Booted, ran, settings works, shell works, apps install
Change-Id: I372e649c019a8f9b95919ff0da6f56612d7061c2
Now requires permission if targeting P.
Note that this is a separate permission from the existing one
that is required for instant apps to use foreground services. The
reason for this is that their semantics are different (the instant
apps permission is associated with an app op for control over what
the app is allowed, while the regular app permission is just a
normal permission that is always granted and only there for
auditing of apps), and there are probably going to be cases where
a developer will want to use a foreground service in the full
version of their app but not as an instant app.
Bug: 72116995
Test: atest CtsAppTestCases
Change-Id: I883c9515c307ed8e39f0bf888c4045944c8183ac
These commands allow a user to set the time and the timezone
from the shell. The shell now has signature|privileged
SET_TIME and SET_TIME_ZONE permissions.
Bug: 67751701
Test: manual - correctly sets the time and timezone from unrooted adb.
Change-Id: I1d2820fd7dadd8b1f3900c0592eb28210370ce88
This change sets LOCAL_SDK_VERSION for all packages where
this is possible without breaking the build, and
LOCAL_PRIVATE_PLATFORM_APIS := true otherwise.
Setting one of these two will be made required soon, and this
is a change in preparation for that. Not setting LOCAL_SDK_VERSION
makes the app implicitly depend on the bootclasspath, which is
often not required. This change effectively makes depending on
private apis opt-in rather than opt-out.
Test: make relevant packages
Bug: 73535841
Change-Id: I4233b9091d9066c4fa69f3d24aaf367ea500f760
Follow-up to ag/3614843 where we started to enforce the permission in
window manager.
Bug: 67109817
Test: builds
Change-Id: Id5712d2ed4c537da3a443f9c51aa15e3c84d670b
UX churn over the years has turned FLAG_ADVANCED into "show internal
storage" which means it's super confusing.
When the Bugreport SAF provider is enabled, just show it.
Test: sure
Bug: 32540478
Change-Id: Id11278c27da8f5f1d1346b208d85b5db59a9e174
System singed components can watch for starting/finishing of
long running app ops. Also protected the APIs to watch op mode
changes with a singature permission for the cross-uid use case.
Test: atest com.android.server.appops.AppOpsActiveWatcherTest
bug:64085448
Change-Id: Id7fe79ce1de4c5690b4f52786424ec5a5d9eb0fa
Skip Bluetooth consent UI if running on shell, also fix a typo in log message.
Test: Manual test running `adb root; adb shell service call bluetooth_manager 6` and see if BT is on without consent UI.
Bug: 69872231
Change-Id: Ie513794a7fc13041259fd84734bfc651495ba5cf
Now requires permission if targeting P.
Note that this is a separate permission from the existing one
that is required for instant apps to use foreground services. The
reason for this is that their semantics are different (the instant
apps permission is associated with an app op for control over what
the app is allowed, while the regular app permission is just a
normal permission that is always granted and only there for
auditing of apps), and there are probably going to be cases where
a developer will want to use a foreground service in the full
version of their app but not as an instant app.
Bug: 72116995
Test: atest CtsAppTestCases
Change-Id: I95afb7185742b82c525e775ca20bb36015510b43
Now requires permission if targeting P.
Note that this is a separate permission from the existing one
that is required for instant apps to use foreground services. The
reason for this is that their semantics are different (the instant
apps permission is associated with an app op for control over what
the app is allowed, while the regular app permission is just a
normal permission that is always granted and only there for
auditing of apps), and there are probably going to be cases where
a developer will want to use a foreground service in the full
version of their app but not as an instant app.
Bug: 72116995
Test: atest CtsAppTestCases
Change-Id: If5a79e7ed5ab9e0edc77410315eb4d2df8ac850b
If a UID is idle (being in the background for more than
cartain amount of time) it should not be able to use the
camera. If the UID becomes idle we generate an eror and
close the cameras for this UID. If an app in an idle UID
tries to use the camera we immediately generate an error.
Since apps already should handle these errors it is safe
to apply this policy to all apps to protect user privacy.
Test: Pass - cts-tradefed run cts -m CtsCameraTestCases
Added - CameraTest#testCameraAccessForIdleUid
Change-Id: If6ad1662f2af6592b6aca1aeee4bd481389b5e00
To protect user's privacy if a UID is in an idle state we allow
recording but report silence (all zeros in the byte array) and once
the process goes in an active state we report the real mic data.
This avoids the race between the app being notified aboout its
lifecycle and the audio system being notified about the state
of a UID.
Test: Added - AudioRecordTest#testRecordNoDataForIdleUids
Passing - cts-tradefed run cts-dev -m CtsMediaTestCases
-t android.media.cts.AudioRecordTest
bug:63938985
Change-Id: I8b0a0889c4aee07f4e1d3c7e4cee0821f2f8cd91
Idle UIDs are ones that were in the background for long enough time.
Currently such apps can access sensor data even though they have no
user perceptible components running. This affects the user's privacy
since an app in the background can use sensor data to infer location,
activity, habbits, etc.
The goal is to restrict sensor access for all apps in the ecosystem
regardless of target SDK which means the solution should be backwards
compatible. At the high level the sesnor service observes UID state
changes and applies policy like this:
Continuous sensors: for sensros in this reporting mode when the UID
goes in the background we will stop dispatching events. Once the UID
goes active we will start reporting the events. While this is an
app visible behavior change we would rather do that vs delivering
fake events.
Flush events: there is no change in behavior based on the UID state.
Hence, idle apps can request a flush and would get the completion
callback. From an app perspective flushing works at any point.
Trigger events: for sensors in this reporting mode when the UID
goes in the background we will not report any trigger events. From
an app perspective the sensor just did not pick up any events.
On-change events: for sensors in this reporting mode when the UID
goes in the background we will not report any change events. From
an app perspective the sensor just did not pick up any events.
Wake locks: since UIDs in idle state cannot acquire wakelocks we
will not be grabbing a wakelock on behalf of apps in that state.
Test: Added - SensorTest#testSanitizedContinuousEventsUidIdle
Added - SensorTest#testBatchAndFlushUidIdle
Pass - cts-tradefed run cts-dev -m CtsSensorTestCases
bug:63938985
Change-Id: Iee73dc034f5fe7fbea789a3b60db4290757c5052
