So that they can be verified by the app calling commit().
This really only makes sense if the app calling commit is different from
the app that created the session.
Bug: 37281396
Test: cts-tradefed run cts-dev -m CtsContentTestCases --test=android.content.pm.cts.InstallSessionTransferTest
Installed and uninstalled packages via the PackageInstaller app
Change-Id: I5c954ca59b7582555bea847f3ddbba0aeefba301
... so that one package can supply the data and another one can issue
the commit.
Also allow reading of sealed sessions.
Also lock more in PackageInstallerSession so that we can be sure the
session is not used by the old package anymore once transferred and that
all calls into the session work on consistent data.
Bug: 37281396
Test: cts-tradefed run cts-dev -m CtsContentTestCases --test=android.content.pm.cts.InstallSessionTransferTest
Installed and uninstalled packages via the PackageInstaller app
Installed and uninstalled packages via the Google Play Store
Change-Id: Id4b7a0071d703b7d18c9f5bf2bd15ebf67086d07
Change from the previous attempt:
- Fixed the helper class. The original version had a few bugs.
- Bundle.readFromParcel() now handles a Parcel with a read-write helper
properly.
** Comparison **
The following charts are the actual measurement with and without the fix,
using "dumpsys system".
- The red bar is "total private dirty".
- The X axsis is time since boot.
Without fix:
- #1 First boot:
-- https://docs.google.com/spreadsheets/d/1CbmU8cQQQw7n7tyqbZi3beRHNuzqcmJgdvzDpi40Q1I/edit#gid=1971317391
-- Private dirty stabilizes at ~16.8M.
-- Loading system packages took 1.8 seconds.
- #2 Second boot:
-- https://docs.google.com/spreadsheets/d/1CbmU8cQQQw7n7tyqbZi3beRHNuzqcmJgdvzDpi40Q1I/edit#gid=982210726
-- Private dirty stabilizes at ~17.5M.
-- Loading system packages took 0.5 seconds.
With fix:
- #3 First boot:
-- https://docs.google.com/spreadsheets/d/1R6lL0AnAp93HnrqWujJFNgOjj6wvGicgDlbDAevbc3g/edit#gid=791764875
-- Private dirty stabilizes at around the same level as #1.
-- Loading system packages took 1.9 seconds.
- #4 Second boot:
-- https://docs.google.com/spreadsheets/d/1CbmU8cQQQw7n7tyqbZi3beRHNuzqcmJgdvzDpi40Q1I/edit#gid=1820894299
-- Private dirty stabilizes at around the same level as #1.
-- Loading system packages took 0.7 seconds.
Package manager start up time with and without the fix:
- (Ignored ones that are too fast; probably the thermal throttling didn't kick in.)
- https://docs.google.com/spreadsheets/d/1CbmU8cQQQw7n7tyqbZi3beRHNuzqcmJgdvzDpi40Q1I/edit#gid=499396796
- Before: 3.5 seconds (average of 5 reboots)
- After: 3.6 seconds (average of 5 reboots)
Package scan speed comparison:
- With the fix, first boot.
08-03 08:49:56.851 1000 779 779 I PackageManager: Finished scanning system apps. Time: 2133 ms, packageCount: 143 , timePerPackage: 14 , cached: 0
08-03 08:49:56.971 1000 779 779 I PackageManager: Finished scanning non-system apps. Time: 121 ms, packageCount: 11 , timePerPackage: 11 , cached: 0
- With the fix, second boot.
08-03 08:53:29.387 1000 779 779 I PackageManager: Finished scanning system apps. Time: 484 ms, packageCount: 143 , timePerPackage: 3 , cached: 143
08-03 08:53:29.424 1000 779 779 I PackageManager: Finished scanning non-system apps. Time: 37 ms, packageCount: 11 , timePerPackage: 3 , cached: 11
** Conclusion **
- This CL wil slightly slow down the boot time (0.2 seconds on a thermal-throttled bullhead), but
the system server's ram consumption will go down to the no-cache level.
- Using the package cache is still faster than not using it.
Test: build, boot, reboot, adb-install, reboot
Test: bit FrameworksCoreTests:android.content.pm.PackageParserTest
Test: bit FrameworksServicesTests:com.android.server.pm.PackageParserTest
Test: cts-tradefed run cts-dev --skip-device-info --skip-preconditions --skip-system-status-check com.android.compatibility.common.tradefed.targetprep.NetworkConnectivityChecker -a armeabi-v7a -l INFO -m CtsOsTestCases -t android.os.cts.BundleTest
Bug: 64112468
Change-Id: I30691a032cb1dd1c7f6c1966a096c2f0d07a09cb
The underlying session may have been destroyed before we go back to
read out the icon.
Test: builds, boots
Bug: 63795821
Change-Id: I16eb32c74a0e3b1d0605392878d65f28437006a6
Disable tests when multi-package APK is disabled.
Test: Ran framework tests with flag both on and off.
Change-Id: I0aae693816af06eebe1bc6cdeebf8dad4c179260
Log time it takes to parse a package (parse=) and update the cache
(update_cache=), if time exceeds 100ms threshold.
This can be useful for analyzing bugreports of slow PM init post-OTA.
Test: manual
Bug: 62462279
Change-Id: I4099b21fae6a5db8c8f1cbc2147a33b9ee51767a
Since appBounds encodes both dimensions and positions, movement will
cause a diff change. This happens in situations where the dimensions
stay constant, such as dragging a PiP window around.
To avoid flooding the client side with configuration changes, this CL
checks whether the new configuration is equivalent to the existing
configuration with the exception of the position of the appBounds
before sending to the registered callbacks.
Change-Id: I8fbc94458fd9ed3b39494c3587f25e704ec02a7d
Fixes: 63927944
Test: bit FrameworksServicesTests:com.android.server.wm.AppBoundsTests
Test: go/wm-smoke
The presence of these new flags leads to issues with application that
do not expect their presence. Since these flags can appear at
critical times, such as on orientation change, these issues are
brought to the surface often.
This CL remedies this problem by first removing the rotation
property. It is not used and the original issue of orientation and
Configuration alignment has been addressed. For app bounds, the CL
reverts the behavior back to identifying diffs as a screen size
change.
Fixes: 64004417
Test: bit FrameworksServicesTests:com.android.server.wm.AppBoundsTests
Test: go/wm-smoke
Change-Id: I1fabb564dfb5c13d897336708523cf7cd5099fa0
We added a couple of protection flags that also apply to
normal and dangerous permissions. These flags are folded
in the protection level breaking apps that directly and
compare against the protection constants. Apps that target
older than O SDK don't get protection flags folded into
the protection level.
Test: All permission tests pass
Added a new test to ensure no protection flags reported
for normal and dangerous permissions
Change-Id: I87b10a7695d8ecfa7156525d6f3d101fc0639513
bug:62755026
