Incremental Serivce periodically polls loading progress and sends to
Package Manager Service. Package Manager provides APIs for other
interested parties to listen to the loading progress.
BUG: 165841827
Test: unit test
Change-Id: I44b9e17c2240b9efe53bc09fc728b6671f1f7dfe
To speed up recurring ApplicationInfo creation, this caches
the the appInfoFlags/appInfoPrivateFlags at parse time, since
they're immutable at that point. This saves having to calculate
it hundreds of times for all the packages in getInstalledPackages
or similar.
This also saves the base app data directories for the system user,
or user 0, interning the strings since they're shared across
packages with the same volume UUID. A better solution would
cache these paths during boot scan and re-use the strings directly
rather than re-building and relying on interning, but there was
no good mechanism for that.
This decreases string append computation time and compromises
between persistent memory and performance.
This also compacts boolean fields into a bitset, decreasing
the amount persisted in both the object memory and the Parcelable
output.
In combination these changes result in a net decrease in memory
usage, although the difference is neglible, on the order of
~4KB for 181 packages or ~22B a package. The increase in speed is
roughly 2/3rds saved off the total time of generateWithComponents.
An important note is that hideAsParsed/hideAsFinal are now
required to be called because they now calculate the derived
fields to be cached.
Bug: 153656459
Test: atest CrossProfileAppsServiceImplRoboTest
Test: atest PackageManagerComponentLabelIconOverrideTest
Test: atest PackageParserTest
Test: atest UserSystemPackageInstallerTest
Test: atest DexoptUtilsTest
Test: atest com.android.server.pm.parsing
Test: atest PackageInfoUserFieldsTest
Test: atest com.android.server.pm.ScanTests
Test: atest android.content.pm.cts.PackageManagerTest
Change-Id: I977edb9dec720893ccb1ce5b9df33733c408d3c1
Apps could use Runtime.exec() to spawn child process and framework
will have no idea about its lifecycle. Now track those processes
whenever we find them - currently during the cpu stats sampling
they could be spotted. If it's consuming too much CPU while its
parent app process are also in the background, kill it.
By default we allow up to 32 such processes; the process with the
worst oom adj score of their parents will be killed if there are
too many of them.
Bug: 160548789
Bug: 157089413
Test: atest AppChildProcessTest
Test: atest CtsAppTestCases:ActivityManagerTest
Change-Id: I95b20a1f36ccd43d09027201d14872305b169d8d
After consulting with the ART team, we learned that sending them
detailed advisory native allocation sizes isn't as useful when the
overall lifecycle of the object is tightly managed, which is the
case with Parcel objects. (Because Parcel users use explicit
obtain() and recycle() methods, any variable-sized native
allocations have already been freed by the time a Parcel instance
is considered for GC.)
The Parcel benchmarks referenced below are showing a uniform ~3%
performance improvement across 1, 4, and 16 thread cases. Note that
this is in addition to the improvements recently made with the shift
to a linked-list pooling design.
Bug: 165032569
Test: ./frameworks/base/libs/hwui/tests/scripts/prep_generic.sh little && atest CorePerfTests:android.os.ParcelObtainPerfTest
Change-Id: Id0ce9b3bff1d0ffb426a9f105c7a54eb00060f85
Repeated locale has not been accepted and IllegalArgumentException
is thrown. Instead of throwing exception, dropping repeated locale
instead.
Bug: 152410253
Test: atest LocaleListTest
Change-Id: I80f243678ac3024eaeb0349f770cff897df7f332
Repeated locale has not been accepted and IllegalArgumentException
is thrown. Instead of throwing exception, dropping repeated locale
instead.
Bug: 152410253
Test: atest LocaleListTest
Change-Id: I80f243678ac3024eaeb0349f770cff897df7f332
transition.
When handling unknown sources, PackageManager transitions from
MODE_DEFAULT to MODE_ERRORED, causing us to kill the app before the user
has even decided whether to allow external sources or not.
Since MODE_DEFAULT and MODE_ERRORED are the same from a storage point of
view, ignore transitions between the two.
This required some AppOps changes to store the previous mode and pass it
in.
Bug: 162849988
Test: run Epic installer
Change-Id: Ic866216f877e9b727fe70556f66dd998966fe0a2
Merged-In: Ic866216f877e9b727fe70556f66dd998966fe0a2
When handling unknown sources, PackageManager transitions from
MODE_DEFAULT to MODE_ERRORED, causing us to kill the app before the user
has even decided whether to allow external sources or not.
Since MODE_DEFAULT and MODE_ERRORED are the same from a storage point of
view, ignore transitions between the two.
This required some AppOps changes to store the previous mode and pass it
in.
Bug: 162849988
Test: run Epic installer
Change-Id: Ic866216f877e9b727fe70556f66dd998966fe0a2
Repeated locale has not been accepted and IllegalArgumentException
is thrown. Instead of throwing exception, dropping repeated locale
instead.
Bug: 152410253
Test: atest LocaleListTest
Change-Id: I80f243678ac3024eaeb0349f770cff897df7f332
This todo doesn't need to happen since we're keeping both the int and float values for backwards compatibility.
Bug: 160141704
Test: manual
Change-Id: I26a5057acd7604578f3021c21a1412d6c1b7b0d6
