The @removed docs tag means that a particular API should be considered
as removed from the API surface area that it otherwise would have been
exposed through.
This set of CLs is fixing a bug where we @removed had been treated as
always removing from the public API.
Bug: 62341924
Test: make -j32 update-api
Change-Id: I336b2df4804e947a0b93a12269d6e7c5594eef7e
There's no need to do this during a "lite" parse. Moreover, we don't
resolve resource references during a lite parse, which means that we
lose a lot of flexibility.
Test: CtsAppSecurityTestCases
Bug: 64339642
Change-Id: I7d02faab6bd226d96d63d2edd8c06b94e15e14ad
Fixes: 37956764
Test: Manual
Test: Create a test app with no handler, see it's not passed to the installer
Test: Create a test app with a handler, see it's passed to the installer
Test: Create a test app with multiple handlers, see one is passed to the installer
Test: Create a test app with a handler defined in a split, see it's not passed to the installer
Change-Id: Idfc3648154afca7ec300019d9695417274118d6f
Change-Id: I2735b3823a8709b2ffb65cc8085ffcd952d3e1f2
Fixes: 64205417
Test: Manual
Test: Create a sample app and install it as a normal app
Test: See that it returns 'false' for "isVirtualPreload"
Test: Create a sample app and install it as a virtual preload ["--preload"]
Test: See that it returns 'true' for "isVirtualPreload"
Test: Run sample apps after reboot and see they return the correct value
Disable tests when multi-package APK is disabled.
Test: Ran framework tests with flag both on and off.
Change-Id: I0aae693816af06eebe1bc6cdeebf8dad4c179260
(cherry picked from commit 17041530bf)
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
