Looper traces handler calls by calling Handler.getTraceName(), which when used with PooledLambda
ends up showing just:
"android.os.Handler: com.android.internal.util.function.pooled.PooledLambdaImpl"
That name doesn't help understand what's the real bottleneck, and even worse, could let people
think it's the PooledLambda who's causing it.
Which this change, it will display names like:
com.android.server.appop.AppOpsService$Lambda
com.android.server.wm$Lambda
Fixes: 141172840
Test: manual verification (neither PoolLambda nor Message have unit tests)
Change-Id: I80d2158a50a644b10f3724fb42a4a9c2aee63ae9
Replaces PackageParser#Package and it's related structures with
ParsingPackage, ParsedPackage, and AndroidPackage.
This is a large scoped CL, the first step in an eventual goal
to refactor how data is handled in the package parsing and install
process. It introduces as few logic changes as necessary. Mostly
migrating to interfaces and renaming, moving parsing data calls into
3 separate interfaces that outline the intended flow for parsing.
ParsingPackage is built and used during what was PackageParser, now
replaced by ApkParseUtils and it's related classes. This is almost
exactly what was parsed from the XML/files on disk.
ParsedPackage is used when the object exits PackageParser and is
adjusted by PackageManagerService to what is considered the final
"parsed" state, adjusted from literal values, but consistent given
the same APK on disk. This should eventually be moved out of PMS
and possibly collapsed into the previous interface entirely.
AndroidPackage is the final state of the package after parsing and
adjustment has completed and no more mutations should be expected.
There are a few exceptions to this, included in AndroidPackageWrite,
which will eventually be refactored into PackageSetting or another
state class.
This marks PackageParser#Package and all the old infrastructure with
@Deprecated, as none of them are used internally. All usages were
converted, and the legacy Package is only built for un-converted tests
and @UnsupportedAppUsage methods.
There are numerous TODOs still outstanding, but addressing them
in this initial CL would introduce several logic changes. They've been
marked with the bug number and will be handled in follow ups.
This is being merged with caution thrown to the wind because
testing this on devices and in development will be the best way
to debug differences introduced by the migration. Getting it merged
as early as possible gives the most amount of time to fix regressions.
Waiting for tests of all the functionality could take literal years
before covering enough to merge this with all regressions verified.
Given a sample size of 4 heap dumps and the caveat it was taken very
early in the migration, there is a memory overhead of about 200 KB
versus the legacy implementation. This should be verified more
accurately and addressed in follow ups.
This CL also kills child/parent package support, since that's
broken already, and difficult to support with the new interface
structure.
Bug: 135203078
Test: booted an emulator, works generally as expected
Specific tests which failed / failed to build were fixed, but because
not all tests are currently passing before this change, not all were
verified.
Change-Id: I4ba050c228e6c60b8f63a9e3347b1f9a57ef794a
Until recently, I and apparently some others were under the assumption
that RuntimeInit.commonInit() runs before the Zygote fork. Actually, it
does not.
This CL introduces a method ZygoteInit.preForkInit() which runs before
the Zygote fork. For now, only enableDdms() moves into it and can become
private. This should not alter behavior since enableDdms() is called
from the same places as before, and because enableDdms() (now private)
was already not part of any API surface.
The CL also removes the qualifier "final" from the (static) method
enableDdms(), because it is redundant.
Note: This CL was uploaded with --no-verify because of preexisting
import ordering issues in RuntimeInit.java
Test: Treehugger
Change-Id: I8f637e160a2d7810feb43b6a43ec7d628af18fb8
Only log once per change-package-state(resets every app launch if used
from within the app process).
Next: reset every app launch for server usage as well.
Test: using the test app.
Bug: 138374585
Change-Id: I5587f7138cf2cd8d144e88cf294e65c14bb32bfb
The APIs behave the same as the AppInfo APIs, and returns the change is
enabled if there is no installed package with the provided name.
Test: flashed device, used the test app, and made the API use the new
per-package API.
Bug: 138275545
Change-Id: Ic925751dddc6c2e0996fe195a208f5c689554839
When Zygote forks a process with the MOUNT_MODE_PASS_THROUGH
flag, bind mount the pass_through path into /storage for the
process, allowing the process to bypass FUSE.
Bug: 140064376
Test: cat /proc/<pid of app with pass_through flag>/mountinfo shows
the lower fs bind mounted directly on /storage
Change-Id: Ia212c2c71ecfdc1629739ca8af171f332ccfca72
Creates a new SystemConfig xml entry which allows a device to whitelist
system packages to be installed on users when they are created, based on
the type of user.
System packages will be installed on users when they are created, or
during OTAs, based on this whitelist. The whitelist can be
enabled/disabled via a Config resource.
For any user type, system packages can be whitelisted or blacklisted.
If it is both (for the same user type), the blacklist takes priority.
If it is neither, it won't be installed (since it isn't whitelisted).
If a system package isn't mentioned in the whitelist file at all, for
any user, then its behaviour depends on the Config resource value, which
can optionally implicitly whitelist all such apps on all users.
For now, the list is mostly empty and the default config is set to be
enabled but implicitly whitelist all system packages that are not
mentioned.
Test: atest FrameworksServicesTests:SystemConfigTest
Test: atest com.android.server.pm.UserManagerServicePackageWhitelistTest
Test: manually test user 0 by flashall -w and checking packages
Test: manually test OTA by setting setprop persist.pm.mock-upgrade 1
Bug: 134605778
Change-Id: Ia098c1f597f66a1c946cfcc9b7771c25e8ceabf7
We need to check the window type and some private flags to figure out if we should
intercept the home key. Instead of holding checking the WindowState associated with
the window token, check a separate map that contains a snapshot of the relevant info.
Bug: 134365580
Test: atest KeyboardInterceptorTest
Test: go/wm-smoke
Test: home key works
Change-Id: Ica60cef649754095f5c1ed6204a9b1581a07bfc6
Navigation bar background wasn't being redrawn
when using legacy navigation bar.
Fixes: 140096278
Test: Open Sheets app, turn landscape, select
a cell, press the "Fx" button on buttom left,
turn portrait and observe no black bar.
Open Sheets app, turn landscape, open recents
and select sheets icon and go into split screen,
choose any other app, click on cell, press "Fx",
turn portrait, observe no black bar.
Change-Id: Ibfe1abdba87a0d66c68478ee206b992c933cd9ad
(cherry picked from commit 7ab1fb8f37)
Sort based on rank only when directly fetching the targets from
ShortcutManager. Otherwise the target from AppPredictionService are
already ordered.
Bug: 140449186
Test: atest ChooserActivityTest
Test: Manual test to verify shortcuts have the same order in Launcher and ShareSheet when AppPredictionService is disabled
Change-Id: I41e08b86746c977c05acea8a5d0654083897741d
Navigation bar background wasn't being redrawn
when using legacy navigation bar.
Fixes: 140096278
Test: Open Sheets app, turn landscape, select
a cell, press the "Fx" button on buttom left,
turn portrait and observe no black bar.
Open Sheets app, turn landscape, open recents
and select sheets icon and go into split screen,
choose any other app, click on cell, press "Fx",
turn portrait, observe no black bar.
Change-Id: Ibfe1abdba87a0d66c68478ee206b992c933cd9ad
Add a new atom and log from both the app process API and the system server API
Bug: 136794938
Bug: 138378110
Test: statsd_testdrive 228
Change-Id: I80f07d0beb30c779c4bce70bebf2bb4ab22f6bfe
Merged-In: I80f07d0beb30c779c4bce70bebf2bb4ab22f6bfe
Add a new atom and log from both the app process API and the system server API
Bug: 136794938
Bug: 138378110
Test: statsd_testdrive 228
Change-Id: I80f07d0beb30c779c4bce70bebf2bb4ab22f6bfe
Merged-In: I80f07d0beb30c779c4bce70bebf2bb4ab22f6bfe
Add a new atom and log from both the app process API and the system server API
Bug: 136794938
Bug: 138378110
Test: statsd_testdrive 228
Change-Id: I80f07d0beb30c779c4bce70bebf2bb4ab22f6bfe
