We used to register the DexLoadReporter after the main class loader
was created. That was done to avoid superfluous reports of the app's
primary apks (since we already know about them).
However that also means that if the app would start as an isolated
process we would miss this signal in the DexManager.
Make sure we get signals for isolated processes by registering the
reporter before we create the main class loader.
Test: manual, using chrome and maps go
adb shell cmd package compile -m speed-profile com.android.chrome
adb shell am start -n \
com.google.android.apps.mapslite/com.google.maps.lite.twa.MapsLiteTwaLauncherActivity
adb shell dumpsys package dexopt
(confirm that chrome is used by an isolated process)
adb shell cmd package compile -m speed-profile com.android.chrome
(confirm that chrome is speed compiled - or verify, based on the device
setting)
Bug: 163018062
Change-Id: I5d683ae85b3973cc2011dd33b4cb14837b18005f
Starting with API level 31, the subscriberId is applicable
for the wifi network. Considering applications may use
null or an empty string as subscriberId (for instance, cts),
frameworks create MATCH_WIFI_WILDCARD NetworkTemplate when querying
wifi network with null or an empty string which is the behavior before
API level 31.
Bug: 188915450
Test: atest -c NetworkStatsManagerTest
Change-Id: I084b69903f8ba7a6225b312560752e8508938714
Retrieval of the system and system UI themes should be done with the
ResourcesManager lock held to ensure the theme retrieved has the new
overlays applied.
Bug: 189100984
Test: manual
Change-Id: Ibe27ec745ea5a914d3d05e393598a336d96a55e6
Changed DPMS#isPackageAllowedToAccessCalendarForUser to always require
INTERACT_ACROSS_USERS/_FULL permission if called for a different uid
than the calling uid.
Test: atest com.android.server.devicepolicy.DevicePolicyManagerTest
Bug: 187043716
Change-Id: I230bbffbdf97c251c8a40add097b3b4254d39452
* changes:
Quantize image to 128 colors instead of 5
Quantizer improvements
Sort colors from high count => low count
Don't interpolate image input to quantizer
Cache set wallpaper as PNG instead of JPEG
Only rescale wallpaper if its > display height
Quantizing an image to five colors results in an extreme amount of
averaging of colors, leading to low chroma colors and erasing colors
from the image that the eye gravitates towards.
Coupled with a change to ensure there's still a broadly accurate signal
of a given cluster's population of the image, via summing the population
of all the clusters close to the hue of the cluster, and with proof that
having this many data points doesn't lead to instability in results,
we gain access to a much larger variety of colors. This gives room to
add heuristics to avoid 'bad' colors, as well as increase the
number of colorful colors we offer.
Bug: 189931209
Test: Test tons and tons of wallpapers over a couple days.
Change-Id: Ifc2d9393039194c151920536b9217ae9636ff0d6
The original versions of these quantizers landed a couple months back,
and they were fine. Since then, we've had several opportunities to
iterate on them. This change lands improvements from those iterations.
TL;DR: 18% faster, big bug fix to WSMeans, code is cleaner (hopefully)
- QuantizerMap indexes an image's pixels, 'unique-ing' them by reducing
the pixel array to a map with keys of colors, and values of population.
This allows other quantizers to operate much more quickly: instead of
working on each pixel individually, they're able to operate in bulk.
- QuantizerWu uses flat arrays instead of 3D arrays and is more
understandable IMHO.
- QuantizerWsmeans has speed improvements, most importantly, it has a
big bug fix. When a Kmeans-based quantizer algo starts, it must first
assign the pixels to any one of the starting clusters. The original
implementation decided what cluster to assign a pixel to by finding the
cluster closest to the pixel. However, the algo terminates if no pixels
moved after one iteration of the algorithm, and since the pixels were
already in the cluster closest to them, the algo would immediately
terminate before it actually figured out where the cluster moved to
after pixels were assigned to it, and had a chance to move pixels around
based on that.
- Funnily enough, even though this _should_ mean Wsmeans got a lot
slower since it has to do more iterations, it is actually 16% faster
Additionally, during review of this CL:
An accidental dependency on iteration order of a Set was introduced,
causing inconsistent initialization of the mPoints array, creating
inconsistent results from the quantizer.
Removing the dependency on hashes of float[], and avoiding Maps
altogether, removes a dependency on hash codes of pointers that existed
during review, making it easier to have verifiable consistency across
iterations. This also improves speed slightly, from 55 ms to 39 ms
(tested on sunfish, first 9 wallpapers in Landscapes, City Scapes, and
Art categories, and averaged)
Bug: 189931209
Test: ran performance tests with VariationalKMeansQuantizer,
the previous Celebi = Wu + Wsmeans quantizer, and the new Celebi =
new Wu + new Wsmeans quantizers, over 100 iterations. Wu speed is
roughly the same, Wsmeans is 18%. Verified quantizer output is stable
for the same input pixels, run 100,000 times for each of two wallpapers.
Change-Id: I3324d29860c098ea1fd602b8d4197837e732f4f1
The colors were being sorted by population ascending, sorting by
population descending fixes a long-standing flaky test that became
a 100% reproducible failure once scaling fixes were introduced.
The test failure that caught this is CTS' WallpaperManagerTest's method
wallpaperColors_secondary. It creates a bitmap that is mostly red, with
a smaller area of blue.
Before the set of 4 CLs in this topic, when the wallpaper was downscaled
by WallpaperManager, it introduced new colors to the wallpaper due to
bilinear filtering and JPEG compression. With the new colors introduced
by scaling, the least popular color was blue enough to pass
WallpaperManagerTest's wallpaperColors_primary method, and the 2nd least
popular color was red enough to pass wallpaperColors_secondary.
With CLs for consistent image input to quantizers, namely 2 CLs, cache
wallpaper as PNG instead of JPEG, and only rescale the wallpaper if it
is greater than the display height, the scaling/JPEG artifacts are not
introduced, which then exposes the bug that primary/secondary were the
least popular/2nd least popular colors in the image, instead of the
most popular/2nd most popular, as intended.
Bug: 188373181
Test: atest CtsAppTestCases:android.app.cts.WallpaperManagerTest
#wallpaperColors_secondary --, use helper methods to store
the bitmap after downscaling to confirm introduction of new colors
before other CLs in this topic, use go/monetstudio to confirm
quantization results from that downscaled image. Check test against
all 4 CLs, confirm test starts failing once "Only rescale wallpaper if
its > display height" CL is introduced.
Change-Id: I143f824fbd961b81604d427a0570b3a171bdeb79
With `false`, nearest neighbor is used during scaling, with `true`,
bilinear interpolation is used. Bilinear interpolation can introduce
colors that weren't in the original image (ex. overemphasizing red/brown
highlights in a mostly B+W image of the Mandolorian). Better to avoid
that.
Bug: 189931209
Test: Test tons and tons of wallpapers over a couple days.
Change-Id: I425f95793ca593dbbc5008ef59f4baedaea318a6
