Add DPM.setApplicationExemptions API along with exemption constants.
Add DPM.getApplicationExemptions API
Add corresponding methods in DPMS along with map of DPM exemptions
constants to app-ops.
Add permission to AndroidManifest to expose to CTS tests.
Bug: 246330879
Test: atest ApplicationExemptionsTest
Change-Id: I1271db694af4091ead951d0167edac55ace92f47
Android T allows apps to declare a runtime receiver as not exported
by invoking registerReceiver with a new RECEIVER_NOT_EXPORTED flag;
receivers registered with this flag will only receive broadcasts from
the platform and the app itself. However to ensure developers can
properly protect their receivers, all apps targeting U or later
registering a receiver for non-system broadcasts must specify either
the exported or not exported flag when invoking #registerReceiver;
if one of these flags is not provided, the platform will throw a
SecurityException. This commit updates all the exposed receivers
with a new RECEIVER_EXPORTED_UNAUDITED flag to maintain the existing
behavior of exporting the receiver while also flagging the receiver
for audit before the U release.
Bug: 234659204
Test: Build
Change-Id: Iaead564629e58a747e481494ead501d30bc23079
unless it has the privileged permission KILL_ALL_BACKGROUND_PROCESSES.
Bug: 239423414
Test: atest CtsAppTestCases:ActivityManagerTest
Change-Id: I35d20539ffac055a6d61260445620f45584bd9c5
In updatePermissionFlags, we're calling clearCallingIdentity. And,
just after doing so, we're calling
enforceCallingOrSelfPermission(ADJUST_RUNTIME_PERMISSIONS_POLICY).
But, these two things don't really make sense together, because the
former nullifies the latter.
We could either:
1. Remove clearCallingIdentity but keep enforceCallingOrSelfPermission,
or
2. Remove both
For security, this CL goes with the first option. But, doing so means
updatePermissionFlags now enforces ADJUST_RUNTIME_PERMISSIONS_POLICY.
And this breaks some CTS tests. To address this, we have to add
ADJUST_RUNTIME_PERMISSIONS_POLICY to the shell identity.
Bug: 190694761
Test: atest ActivityPermissionRationaleTest
Change-Id: I7031aebf69d9ec919334573b99eb6b7cb8be31d0
Allow apps to trigger the dump of certain critical data, e.g. data stored in short
ring buffers that might get lost by the time a bugreport is requested.
Then, a bugreport request can specify whether the pre-dumped data should be used.
Fixes: 205138504
Test: atest com.android.os.bugreports.tests.BugreportManagerTest
Change-Id: I55c7b53e235ebf2baa694e6fdc4e4a321a459c8b
Grant FULL_ACCESS_CELL_BROADCAST_HISTORY permissions to the shell identity for use within CellBroadcast MTS tests.
Bug: 236217191
Bug: 227422973
Test: atest com.android.cellbroadcastreceiver.compliancetests.CellBroadcastConfigTest
Change-Id: Ief5a4c168968b4dc8c9cf7cc071618d41c23d220
In order to remove SurfaceControl.getInternalDisplayToken, we need to
replace all usages of it. The primary use is for screen capturing since
you could call directly into SF via ScreenCapture.captureDisplay if you
had a display token. However, this isn't scalable with multi-display
since you need to be explicity which display to capture.
The change provides a new API into WMS to capture a display using the
displayId. This is still a privilege call so only processes with
READ_FRAME_BUFFER can use it. In most cases, the replacement for now is
to use DEFAULT_DISPLAY, but they can be modified later to send the
desired display.
Test: power + volume down
Test: assistant screencapture
Test: SurfaceViewTests
Bug: 242714168
Change-Id: I9b406b699d48ae34c6ffd91c34941f1580f38d28
This API can be used from calls outside applications to create a virtual
display for mirroring. The permission checks in system server are still
in place so the caller must have CAPTURE_VIDEO_OUTPUT permission. This
class is intented to be used by systems that to stream device content,
but not from an application. In most cases, this will be called from
Shell or a system application.
Test: MediaProjectGlobalTest
Bug: 237664947
Change-Id: I43f79c83db7c82c0b682ef174fb1a5ab83795489
The API will be available in CTS so that we can use it directly instead
of calling it from other system components.
Bug: 240602359
Test: Build & call the API from CTS
Change-Id: I8aa6ee85adb62cda67479c7213d2bc022acd0eec
IInputMethodManager#isInputMethodPickerShownForTest() was introduced
in Android P (API 28) to verify IME picker visibility in CTS [1].
To make it clear that that IPC method must be available only for
special testing purpose, this CL introduces an @hide permission
android.permission.TEST_INPUT_METHOD
and requires it in
InputMethodManagerService#isInputMethodPickerShownForTest().
This CL grants that permission to the shell process hence CTS tests
can still access to the corresponding test API by using
UiAutomation#adoptShellPermissionIdentity().
[1]: I4e21625c32a0ca1abc740229efb3c7fcd97141cc
eb5706183f
Bug: 237317525
Test: atest CtsInputMethodTestCases
Test: Manually verified as follows.
1. adb logcat -b events | grep 237317525
2. atest CtsInputMethodTestCases:InputMethodManagerTest#testIsInputMethodPickerShownProtection
Ignore-AOSP-First: For a security fix
Change-Id: Ie79a3e9d41ce22605ae083594d639c37d08b7def
Add a Y2038 check into the time_detector and add infrastructure to allow
command-line testing to confirm it works.
This is before removing a Y2038 check from NITZ parsing code in the
telephony process. After this change, Androdi will consistently block
>= Y2038 suggestions, not just time signals that come in via telephony.
The initial checks attempt to limit the restriction to devices with
32-bit ABIs, since the main issue we're aware of is that time_t is a
32-bit signed int under bionic, hence there could be issues with that
type in 32-bit processes on 32-bit / mixed 32/64-bit devices.
Bug: 204193177
Test: adb shell cmd time_detector suggest_network_time --reference_time 2480587 --unix_epoch_time 1646473966056
Test: Run with 32-bit + 64-bit only builds, inspect adb shell dumpsys time_detector
Merged-In: Ib9d6472f5ca7a62d59b3224f1845846f99a0b52d
Change-Id: Ib9d6472f5ca7a62d59b3224f1845846f99a0b52d
