Multiple MinikinFontSkia objects can share the same font file if they
are using .ttc or variable font.
Bug: 172891184
Test: atest CtsGraphicsTestCases
Change-Id: I73c307ec1752a5a016b4b8e91b375e6322894f8a
Use of binder::Status exceptionCode is more reliable than
transactionError, especially when calling a Java service.
Test: builds
Bug: 175361278
Change-Id: Iaafb1007f07c7abc22985f0d63f23a0358d6b194
After CL[1], the client might be waiting forever when
system server throw Exception. The expected behavior
after throwing an Exception from the system server
should let the caller crash.
To keep the previous behavior, support exception as a
valid result for ResultCallback.
CL[1]: If4b40244a2e0e3b11c38c1da9340ba8e5166ad64
Bug: 174263942
Bug: 163453493
Test: Throw an exception in system server and observe the
caller crash with ResultCallback flow.
Test: atest CtsInputMethodTestCases
Change-Id: If79e063641a01b325c63eb9f871f5b992d7c0b72
* changes:
Remove support for legacy network agents
Remove deprecated constructors for NetworkAgent
Migrate NetworkAgentWrapper to the new NA API
Cleanup TestNetworkService
http://ag/12885739 introduced a enforceCallingPermission(BACKUP) check
but callers of this API do not hold that permission. This CL fixes
this by changing the check to enforceCallingOrSelfPermission(BACKUP),
and clearing the binder identity in DevicePolicyManagerService, which
makes the system server process the owner of that call.
Bug: 158482162
Bug: 172466964
Test: atest com.android.cts.devicepolicy.{Device,Profile}OwnerTest#testBackupServiceEnabling
Change-Id: I11d863229c4d62a058aaf37446a694b9c73ae5b8
Merged-In: I11d863229c4d62a058aaf37446a694b9c73ae5b8
(cherry picked from commit 630dec9eb4)
Base CL ag/12885739 introduced unconditional enforcement of the BACKUP
permission for callers of BackupManagerService.isBackupServiceActive()
in the service, but dropped the enforcement on the app process side
(BackupManager).
This CL makes the behavior change conditional on a compat ChangeId.
Bug: 158482162
Test: Manually checked that an app similar to the code sample from
http://b/158482162#comment1 can reproduce the behavior.
This is true both before the base CL and after this CL, when
the app targets an old SDK version (26).
Test: Checked that both (a) before this CL, (b) after this CL where
the change is manually enabled for the app via the below commands,
the app runs into a SecurityException instead:
$ adb shell am compat enable 158482162 com.example.tester
$ adb shell dumpsys platform_compat | grep 158482162
ChangeId(158482162; name=IS_BACKUP_SERVICE_ACTIVE_ENFORCE_PERMISSION_IN_SERVICE; enableSinceTargetSdk=31; packageOverrides={com.example.tester=true})
Change-Id: I58e5d2a0b438296137fd76720636c8fdce740ded
Merged-In: I58e5d2a0b438296137fd76720636c8fdce740ded
(cherry picked from commit 7671f0d95c)
BackupManager runs in the client process, whereas BackupManagerService
runs in the system server process. Therefore, apps permissions need should
be enforced on the service side.
Bug: 158482162
Test: Manually checked that a sample app encounters SecurityException
after but not before this CL, when running code similar to the
sample in http://b/158482162#comment1 to figure out whether
isBackupServiceActive() for its own uid.
Change-Id: I59693819542a80a065a9c88373393b0ba0dbef65
Merged-In: I59693819542a80a065a9c88373393b0ba0dbef65
(cherry picked from commit b2ab2c414f)
A number of permission-related methods were implemented in
ApplicationPackageManager by calling the IPermissionManager AIDL
interface. However since we are moving permission into module, the
AIDL inteface can't be an API and the implementions must be moved.
This change moves these methods into PermissionManager, with the
javadoc and interface from PackageManager and the implementation from
AppliationManager. The javadoc remains mostly the same except for
style and typo fixes. The API interface also remains the same except
for inclusive language changes since we are defining new one and have
a chance to fix them now.
We have to lazily get the PermissionManager instance because the
context passed in may be null for an instrumentation use case.
Bug: 158736025
Test: presubmit
Change-Id: I1c28433ca6200679a41e3518354fe03b866621b5
And move their implementation from PermissionManagerService to
LegacyPermissionService.
The DefaultPermissionGrantPolicy related methods are not APIs, and
are thus moved to LegacyPermissionManager and their usages are updated
to use LegacyPermissionManager.
The checkDeviceIdentifierAccess() method is also moved into
LegacyPermissionManager, because it's merely an application of
permission checking, not the permission management infra itself, and
there isn't great benefit in updating it. However since it is an API,
we still have to keep a delegate for it on PermissionManager, and make
the delegated method @SystemApi.
Bug: 158736025
Test: presubmit
Test: LegacyPermissionManagerServiceTest
Change-Id: Ic838f3685427217c8e0477551c3373258408983f
Currently, only the top-most activity of a root task can be resumed,
no matter how many descendant tasks or their windowing modes are.
Resuming the top activities of all visible and focusable leaf tasks
to be more flexible and can support features like app-pairs.
Therefore, Task#mResumedActivity is now set at leaf task vs. root task.
And Task#getResumedActivity() now returns the resumed activity of the
top-most leaf task. Same as Task#mPausingActivity.
Bug: 172885410
Test: presubmit
Change-Id: Id0a73b39afd03afb2b9572752e98adce8de1619b
