To make S finalization easier, this changes the framework SDK so that
apps linking against it will be able to continue working as expected
after the first phase of SDK finalization.
During the first phase of SDK finalization, the resource ids of
resources that have not been removed are finalized.
staging-public-group tags are converted to staging-public-group-final
tags in order to encode into the framework what the staged resource id
of a finalized resource was. When an app recompiles, it will use the
finalized resource id. Then after all apps recompile, phase 2 of
finalization begins, in which the staging-public-group-final tags are
removed so apps can no longer use the staged resource ids.
Apps that link against the SDK (provided they are using a recent
version of aapt) will encode references to staged resources as
TYPE_DYNAMIC_REFERENCE and TYPE_DYNAMIC_ATTRIBUTE. The values of R
fields for staged resources are defined out-of-line to prevent them
from being inlined into apps linking agsint the SDK. This allows the
resource ids to change during phase 1 of API finalization.
Bug: 183413192
Test: `aapt2 diff` and resource ids stayed the same
Test: `aapt2 dump` of framework-res.apk and observe staged resources
Change-Id: Ie2275c608297a5f63dde8b1cf795415112cbcc24
ResourcesProvider#finalize called ApkAssets#close. ApkAssets#close is
called during ApkAssets#finalize. If a ResourcesProvider and its
corresponding ApkAssets are finalized concurrently, there may be a
chance that the ApkAsset could be finalized first and then
ResourcesProvider calls ApkAssets#close on the object that has already
been finalized.
This may not fix the bug, but there is no reason to close the ApkAsset
during finalization of the ResourcesProvider.
Bug: 159041693
Test: none
Change-Id: I317ca982df2e11a18ccd6c95c74565dbac417bd6
Previous work implemented getRequestedPermissions() by dynamically
constructing the legacy list of requested permissions, along with a
deprecation message to migrate to ParsedUsesPermission, but there
are too many callers to migrate at this stage of the release.
For now, to mitigate performance issues that arose, this change
builds a parallel list of requested permissions to avoid the
overhead of dynamically building the legacy list.
Bug: 183223056
Test: atest FrameworksServicesTests:PackageParserTest
Test: atest com.android.server.pm.parsing
Test: atest -p core/java/android/content/pm \
core/java/com/android/internal/content \
services/core/java/com/android/server/pm \
services/tests/servicestests/src/com/android/server/pm
Change-Id: I538fbc12a9fd34f5ad5d63177ac5a2cb9a1ff3ce
Also added some logging for runtime permissions with no app op
bug: 184093962
Test: Setting up device with work account
Change-Id: I85787367b11d57ed1240fcf484ad7d2efa13d406
As we allow non-resizable app in multi-windowing mode, the previous
comment can be confusing.
Bug: 176061101
Test: udpate comment
Change-Id: Iba51ca4158940bbda761fe3b7977d338ee1f3327
When an app is proxying access to runtime permission protected
data it needs to check whether the calling app has a permission
to the data it is about to proxy which leaves a trace in app ops
that the requesting app perofmed a data access. However, then the
app doing the work needs to get the protected data itself from the
OS which access gets attributed only to itself. As a result there
are two data accesses in app ops where only the first one is a
proxy one that app A got access to Foo through app B - that is the
one we want to show in the permission tracking UIs - and one
for the data access - that is the one we would want to blame on
the calling app, and in fact, these two accesses should be one -
that app A accessed Foo though B. This limitation requires fragile
one off workarounds where both accesses use the same attribution
tag and sys UI has hardcoded rules to dedupe. Since this is not
documented we cannot expect that the ecosystem would reliably
do this workaround in apps that that the workaround in the OS
would be respected by every OEM.
This change adds a mechaism to resolve this issue. It allows for
an app to create an attribution context for another app and then
any private data access thorugh this context would result in a
single app op blame that A accessed Foo though B, i.e. we no longer
have double accounting. Also this can be nested through apps, e.g.
app A asks app B which asks app C for contacts. In this case app
B creates an attribution context for app A and calls into app C
which creates an attribution context for app B. When app C gets
contacts the entire attribution chain would get a porper, single
blame: that C accessed the data, that B got the data from C, and
that A got the data form B. Furthermore, this mechanism ensures
that apps cannot forget to check permissions for the caller
before proxying private data. In our example B and C don't need
to check the permisisons for A and B, respectively, since the
permisisons for the entire attribution chain are checked before
data delivery. Attribution chains are not forgeable preventing
a bad actor to create an arbitrary one - each attribution is
created by the app it refers to and points to a chain of
attributions created by their corresponding apps.
This change also fixes a bug where all content provider accesses
were double counted in app ops due to double noting. While at
this it also fixes that apps can now access their own last ops.
There was a bug where one could not pass null getting the attributed
ops from a historical package ops while this is a valid use case
since if there is no attribution everything is mapped to the null
tag. There were some app op APIs not being piped thorough the app
ops delegate and by extension through the app ops policy. Also
now that we have nice way to express the permission chain in a
call we no longer need the special casing in activity manager to
handle content provider accesses through the OS. Fixed a bug
where we don't properly handle the android.os.shell calls with
an invlaid tag which was failing while the shell can do any tag.
Finally, to ensure the mechanims is validated and works end-to-end
we are adding support for a voice recognizer to blame the client
app for the mic access. The recognition service can create a blaming
context when opening the mic and if the mic is open, which would
do all permission checks, we would not do so again. Since changes
to PermissionChercker for handling attribution sources were made
the CL also hooks up renounced permissoins in the request permission
flow and in the permission checks.
bug:158792096
bug:180647319
Test:atest CtsPermissionsTestCases
atest CtsPermissions2TestCases
atest CtsPermissions3TestCases
atest CtsPermissions4TestCases
atest CtsPermissions5TestCases
atest CtsAppOpsTestCases
atest CtsAppOps2TestCases
Change-Id: Ib04585515d3dc3956966005ae9d94955b2f3ee08
This is done so that these changes can be overridden in CTS tests and
later via the phonesky installer.
Bug: 183406442
Test: atest WmTests:SizeCompatTests
Change-Id: Idd09349dddbffb8a026d334d1687007b439b87af
The PackageParser is deprecated, but the inner class SigningDetails
is still used widely. To move away from PackageParser, we need to
have an alternatives of theis inner classes.
Bug: 174723245
Test: make
Change-Id: I6ad52b6fb7f4a846713e738f3e64d4642ebbc5ac
PackageParser is deprecated, but system still references its
sUseRoundIcon. We should move that to PackageParserUtils.
Bug: 180603085
Test: manually check if the icon has the white border
Change-Id: Idb2ccc2be9006237244aabfe9c45814e9c7c27b5
Something was left behind when we opened the installation API.
Bug: 152310230
Test: atest PackageManagerShellCommandTest PackageManagerShellCommandIncrementalTest IncrementalServiceTest PackageManagerServiceTest ChecksumsTest
Change-Id: Ia2d4c3f3e97c8432fcca094d6e0f4e97dcc048d4
It's now possible to define an lStar attribute.
This attribute will modify the base color in a way that its chroma will
be conserved, but perceptive luminance will change.
Fixes: 183609373
Test: atest ColorStateListTest
Change-Id: I341a0a532bd9c030e8f52185bacda0db55486216
