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
A new API [getNamesForUids] was recently added to the PackageManager
and this API needs to be accessible to native code. However, there
were two constraints:
1) Instead of hand-rolling the binder, we wanted to auto generate
the bindings directly from the AIDL compiler.
2) We didn't want to expose/annotate all 180+ PackageManager APIs
when only a single API is needed.
So, we chose to create a parallel API that can be used explicitly
for native bindings without exposing the entirety of the
PackageManager.
Bug: 62805090
Test: Manual
Test: Create a native application that calls into the new service
Test: See the call works and data and returned
Change-Id: Ia571ab1607c6c88fef44eb0de6a313a28906c732
The underlying session may have been destroyed before we go back to
read out the icon.
Test: builds, boots
Bug: 63795821
Change-Id: I16eb32c74a0e3b1d0605392878d65f28437006a6
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
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 reproted
for normal and dangerous permissions
bug:62755026
Change-Id: I72547b0146e6b6919803e33ff64b7208c4a255ad
Record the class loader context for secondary dex loads and pass it to
dexopt during compilation.
The class loader context is passed from libcore every time a
BaseDexClassLoader is created and its recorded in the package dex usage
file.
Note that the context may be:
- unknown: if the dex file was not use after the the upgrade and its
context was not yet updated
- unsupported: if any of the class loaders from the loading context is
unsupported (only PathClassLoader and DelegateLastClassLoader are
supported).
- variable: if it changes over time, form one run to another.
In all the above cases the old compilation behavior is preserved for
now.(i.e. the dex file with be compiled with SKIP_SHARED_LIBRARY_CHECK)
Bug: 38138251
Test: runtest -x
services/tests/servicestests/src/com/android/server/pm/dex/
adb shell cmd package compile -f -m quicken ^Csecondary-dex
com.google.android.gms
(cherry picked from commit 3bec94d78b)
Change-Id: Ie8b78c7c0d5de43733b3d116f8dcb3a65324cca8
App bounds are an internal Configuration field and should not
influence the diff that determines whether the Configuration has
changed. This changelist ensures this by introducing a new flag that
is identified server side and filtered before informing the client
that the configuration has changed.
Change-Id: Ibf1387f73eaa9b39e6213e1a1109c4cd57554e7c
Fixes: 63927944
Test: bit FrameworksServicesTests:com.android.server.wm.AppBoundsTests#testAppBoundsConfigurationDiff
Test: go/wm-smoke
Change-Id: I43c8c331883b5b381fb0f133fff448f3a57d0fe5
Bug: 36446542
Test: Manual
Test: Create a stub and a compressed application; put on the /system partition
Test: Restart the system and see that it decompresses the full application onto the /data partition
Test: Restart again and see that we skip decompression
Test: Create an invalid compressed application [eg. empty file]
Test: Restart the system and see that the stub is disabled
Test: Restart again and see that we skip decompression
Virtual preloads are applications that aren't actually on the
/system partition, but, act as if they were. One such distinction
is that these apps receive Intent.ACTION_BOOT_COMPLETED and start
out of the stopped state.
Change-Id: I812d3e7008b9d87e84aa33dbc4b3d8e8b334533c
Fix: 34855677
Test: Manual
Test: Install an app with "--preload"
Test: See that it receives Intent.ACTION_BOOT_COMPLETED
