PackageInfoWithoutStateUtils is designed for use in core when
the caller doesn't have a PackageSeting.
Because its generic generateApplicationInfo method does a simplified
checkUseInstalled check without the PackageSetting, this fails whenever
state must be taken into account.
This introduces method variants which skips the checks and defers to
PackageInfoUtils's own check.
Bug: 150328400
Test: manual verify call into PackageManager#setSystemAppState with
SYSTEM_APP_STATE_UNINSTALLED and verify
PackageManager#getApplicationInfo throws NameNotFoundException
without fix and succeeds with fix
Test: atest com.android.server.pm.parsing
Test: TODO PackageInfo(WithoutState)Utils test in follow up change
Change-Id: Ie00984c2e1b80d2a3948923dc1293fbfddf01037
There are cases where an app can ship overlays for itself,
but the "signature" policy as described would open up
a vulnerability by allowing the system actor to create
and sign any arbitrary overlay that will apply to the target.
To prevent this, redefine "signature" as target package only,
and introduce "actor" for checking against the actor signature.
Any app that wishes to use both can include both policies.
Bug: 130563563
Test: m aapt2_tests idmapt2_tests and run from host test output
Test: atest libandroidfw_tests
Change-Id: I1c583a5b37f4abbeb18fc6a35c502377d8977a41
with appOp as String and options as Bundle
Bug: 139077993
Bug: 146423958
Test: Build
Change-Id: I5325e08d60016741139251813a5df9b42f2efc82
Merged-In: I5325e08d60016741139251813a5df9b42f2efc82
4579c0aea2 changed the method signature
of the constructor of ResourcesKey, which is marked
UnsupportedappUsage. Restore the previous signature and provide a new
constructor that is hidden.
Bug: 147359613
Test: none
Change-Id: I391167e9064b1d88f4ad75200a190e5e3b0968cf
ApplicationInfo now automatically tries to "squash" the same instances in a
Parcel.
NOTE: This CL still does *not* optimize the package manager APIs that return a
list. e.g. PM.queryContentProviders() still return duplicate AppInfo's.
We can optimize them by making ParcelableListSlice call "allowSquashing",
but that *could* have negative side effects, so I'm not doing it in this CL.
I think we can do that for S.
Bug: 148588589
Test: atest CtsContentTestCases # except for two preexsiting failures:
- android.content.pm.cts.PackageManagerTest#testGetIcon
- android.content.pm.cts.PackageManagerTest#testGetPreferredActivities
Test: Use the debugger and make sure bindApplication() is not receiving
duplicate AppInfo's in the provider list.
Change-Id: I3ba2c047a469169340c0f75c36bdfd394bc5d627
(cherry picked from commit 7d09275d70)
Serialising package restrictions uses synchronous disk access; callers
of these methods should probably use background threads for this.
Bug: 149216360
Test: TreeHugger
Change-Id: I6607a7225bf7daaad8a78e4d1e4c585ba5ac3efc
Signed-off-by: Julius D'souza <jdsouza@google.com>
We use the package settings class as a central point for invalidating
on package information changes; for permission changes, we invalidate
from inside the individual permission data objects.
Bug: 140788621
Test: boots, package tests (pending)
Change-Id: Iec14d4ec872124e7ef4612c72d94c89a7319ace0
Make obtaining a visual service from non-visual Context instance
report a strict mode violation and print the stacktrace.
Make calling getDisplay() throw an exception if called on an instance
that is not associated with a display. For existing usages introduce
a new internal method that does not perform the verification until
the usages are properly fixed.
Bug: 128338354
Test: StrictModeTest#testIncorrectContextUse_GetSystemService
Test: StrictModeTest#testIncorrectContextUse_GetDisplay
Change-Id: Id25d590eca6e10066e55d7ed6436d3bc9e433beb
* changes:
Remove AndroidPackageWrite
Migrate to new ParsedComponents and ParseResult
Split ParsedComponents
Add ParseResult infrastructure
ParsingPackage/ParsedPackage test code migration
ParsingPackage/ParsedPackage split source migration
Important migration for new ParsingPackage/ParsedPackage split
Separate ParsingPackage into core and ParsedPackage into server
Original commit:
[DexLoadReporter] Report classloader contexts directly from classloader
At the moment classloader contexts are incorrectly computed in the
PackageManager for secondary dex files. There are two issues:
(1) The wrong computed classLoaderContext will be reported for a secondary
dex file if it was loaded at the same time as a primary dex file
- This is due to the continue statement that doesn't increment
dexPathIndex
(2) If a secondary dex file was loaded with a shared library then that
shared library info isn't passed through the dex load reporting
infrastructure, and thus its classloader context is incorrectly computed
in PackageManager.
In order to fix the issues described above & prevent further classloader
context computation divergences between the package manager and the
runtime, lets compute the classloader context in the runtime at dex load
time and report the expected classloader context directly to
DexLoadReporter (and thus the package manager).
Notes: This is mostly just a refactor (i.e. there are a lot of line
changes, but functionally speaking this set of CLs doesn't do much
except change where the classloader context is computed)
Addendum: The bugs described above could also be fixed by:
- changing DexLoadReporter to report information about shared libraries that
the reported classloaders depend on to PackageManager
- Teach DexoptUtils.processContextForDexLoad about shared libraries
- Fix dexPathIndex calculation in DexManager
I opted for this set of changes instead because this reduces the
possibility of context computation divergence between the framework and the
runtime. Additionally it feels more "solid" that the classloader context
is now computed directly when a dex file is loaded, rather than the
context recreated later on in the PackageManager.
Test: atest com.android.server.pm.dex.DexManagerTests
Test: atest com.android.server.pm.PackageManagerServiceTest
Test: Install app depending on shared library & uses secondary dex
files; adb shell pm bg-dexopt-job; launch app and see odex file
successfully loaded (from smaps/no logcat errors)
Bug: 148494302
Exempt-From-Owner-Approval: This is a pure re-revert, previously owner approved.
Reason for revert: Re-land
Reverted Changes:
I295a6e99e:Revert "Fix shared libraries not being reported vi...
Ib58066e8f:Revert "[DexLoadReporter] Report classloader conte...
Change-Id: I8d1af791f93a3f8fa6eca78df50891cd2ebbb4a3
Removes the massive old ComponentParseUtils in favor of
the new split classes.
Cleans up the parsing code to be uniform, removing the
String[] outError pattern in favor of ParseInput.
Bug: 135203078
Test: atest com.android.server.pm
Change-Id: I584ed37d4715300453dbe760d45d1eb4759b3dd3
This creates individual files for each Parsed_ object.
Each also has a corresponding _Utils class for holding the
parsing logic for each object. This was done to keep the data
class as simple as possible.
This commit does not migrate existing usages of ComponentParseUtils
subclasses, so there will be duplicates of everything. A follow up
change will migrate all the parsing logic to use these new classes.
Bug: 135203078
Test: none, all testing for Parsed_ is to-be-merged and/or TBD
Change-Id: I7bea3b1742bc5d945d1ad287f406488d3bf46476
ParseInput is passed into all parsing methods and simply acts as
a shared container which can hold a generic success or error value.
When it is transformed into a result value, it must be returned to
its parent immediately, who can decide what to do with it.
ParseResult is the type returned when a ParseInput is set to success
or error. It casts itself to a strong type representing the returned
value, and is used by specifying ParseResult<ResultType> instead of
just ResultType for the method return type.
ParseTypeImpl is just the implementation of the two above which handles
moving between them. It also adds some debug functionality in case
the error catching code is incorrect or insufficient and it would be
preferably to always have a stack trace.
It is important to use this infrastructure in a thread-local manner,
such that you don't re-use an input already in use and always bubble
up on any success or error.
A constrained example:
class Parser {
val shared = ParseTypeImpl<>()
fun parse(file: File): Pair<Output, Output> {
// Reset the shared object
val input = shared.reset()
// Pass it to be used by the parsing method
var result = parseOutput(input, file.read())
// Verify the result
if (result.isError()) {
// Bubble up error if necessary
throw Exception(result.errorMessage, result.exception)
}
// Save the result (as it will be lost when the input is reused)
val one = result.result
// Parse something else
result = parseOutput(input, file.read())
// Same verification
if (result.isError()) {
// Bubble up error if necessary
throw Exception(result.errorMessage, result.exception)
}
val two = result.result
return one to two
}
fun parseOutput(input: Input, read: Object): ParseResult<Output> {
return if (read == null) {
input.error("Something went wrong")
} else {
input.success(read)
}
}
}
Bug: 135203078
Change-Id: I532d0047e67f80fd925b481dac8823ab45ad0194
DocumentsUI currently hard-codes the IntentForwarderActivity class name.
It uses this to determine whether to show a 'switch to personal profile'
button. Essentially, it wants to know if the intent it received is a
cross-profile intent, so it asks package manager which intents can
resolve it and checks whether one of them is IntentForwarderActivity.
This is not CTS-enforced, so this CL ensures that it is. OEMs can remove
or rename IntentForwarderActivity as long as they update this API and
keep the corresponding CTS test passing.
Bug: 149568382
Bug: 136249261
Test: atest CtsDevicePolicyManagerTestCases:com.android.cts.devicepolicy.ManagedProfileCrossProfileTest#testCrossProfileIntentFilters
Change-Id: I51916c13320420068987925ac979e59bef3b660d
Part of the Parsing/ParsedPackage split into core/server.
This migrates any core/services source with trivially reviewable
changes. Import changes, moving files around, or generally
small single line changes scattered throughout all code that
depended on the old state of the package code.
Bug: 135203078
Test: enumerated in first commit of change ID
Ib4fe51d729a56bfb0ea1316e577358ba0dfceccf
Change-Id: If091641a81be2d943d1d3e4a3d654e200d0ce59d
Part of the Parsing/ParsedPackage split into core/server.
This splits all the "important" changes, or those which change
significant code/logic and that requires a closer look during
review.
Bug: 135203078
Test: enumerated in first commit of change ID
Ib4fe51d729a56bfb0ea1316e577358ba0dfceccf
Change-Id: Ie0e4394de2b3063121d850060fcd58622511c59d
PackageParser exists in the core framework SDK, and so callers
to it would not not expect a call into the system server.
However, some planned features require parts of parsing to exist
in the server so that package state/settings contained in the
server can be applied to the package.
To resolve this, separate ParsingPackage and ParsedPackage
through a hard boundary, where ParsingPackageImpl is roughly
equivalent to the previous PackageImpl, and the new PackageImpl
is everything that should exist in the server and not core.
This also copies over documentation and cleans up the data models
significantly. The fields have been moved to @NonNull, and in
preparation for true immutability, all Collection structures
have moved to generic types and assigned Collections#empty_().
This begins moving away from @hide AppInfo fields, so internal
use of flags/privateFlags is deprecated. It is now replaced by
straight booleans. For simplicity's sake, existing flags have
also been migrated.
This is split for readability and will not compile without
the followup commits.
Bug: 135203078
Test: atest com.android.server.pm.parsing
Test: atest PackageParserTest
Test: atest PackageParserLegacyCoreTest
Test: atest ScanTests
Test: atest ParallelPackageParserTest
Test: manual toggle and run AndroidPackageParsingTestBase
Change-Id: Ib4fe51d729a56bfb0ea1316e577358ba0dfceccf
* changes:
Clear preferred activities affected by MIME groups changes
Implement new API to modify MIME groups by adding/removing MIME types
Add mimeGroup tag to intent filters
