- 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
Adds the possibility of presenting a custom message on
the keyboard if you're trying to dismiss the keyguard.
This is particularly useful when you're showing the
bouncer because custom authentication (SmarLock)
failed.
Test: launch FLAG_SHOW_WHEN_LOCKED activity and
call KeyguardManager#requestDismissKeyguard
Fixes: 63940122
Change-Id: I0d88c0e59521887efa56d74874062b2b14970e4e
We recently created a new GID that can be granted to critical system
processes, so that the system is usable enough for the user to free
up disk space used by abusive apps.
Define a permission for the GID so we can grant it to system apps,
and add the GID to core apps needed for system stability. (The list
was mostly derived from filling a disk and seeing what caused the
device to fall over.)
Test: builds, boots
Bug: 62024591
Change-Id: Icdf471ed3bed4eeb8c01f1d39f0b40c1ea098396
This change adds a special flag when binding to a service to request
instant apps to be considered as well (assuming the caller has the
permission to see instant apps). This flag is scoped only for the
platform to use and is intended only for development and testing.
Specifically, we have a class of CTS tests that has tests plus service
in the same APK (accessibility, printing, autofill, any other plugin
based sub-system).
Instead of doing the tediuous work split all these into one APK with
tests and one with the services where the latter exposes a remote
interface to the former, we will be adding shell commands to the
dedicated sub-system to allow temporary binding to plugins provided
by instant apps. The goal is not validating the plugin behavious,
rather a working plugin is required to test app side funcionality.
This change adds a shell command to allow the a11y manager serivce
to bind to plugins provided by instant apps. This is required to
be able to run relevant CTS test cases in instant mode.
Test: cts-tradefed run cts-dev -m CtsAccessibilityTestCases
cts-tradefed run cts-dev -m CtsAccessibilityServiceTestCases
Bug: 70978575
Change-Id: Ifced735a9a6e495747372dd8b00fdd64933a09c7
