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
This reverts commit e41b029d85.
Reason for revert: b/189985437
com.android.tradefed.targetprep.TargetSetupError[APK_INSTALLATION_FAILED|520001|DEPENDENCY_ISSUE]: Failed to install com.android.devicehealthchecks with ...
Change-Id: I06fe7d94f6dab474c74b093de8692f08d4031b62
Instrument jank and latency of unlock animation.
Bug: 169735612
Bug: 169735198
Bug: 169220953
Test: take trace to validate
Change-Id: I1721d7d3373f99b4aca618f86464d44ecd1e618e
Support a custom configuration while beginning the instrumentation, also
support a custom tag for getting fine-grained CUJ in the trace.
Bug: 187495856
Test: take the trace, see the cuj section name.
Change-Id: Ife2554e0d7dbe4c01b7e4381a12a5f595e2f4364
Attribution source is the abstraction to capture the data
flows for private data across apps. Checking permissions
for an attribution source does this for all apps in the
chain that would receive the data as well as the relevant
app ops are checked/noted/started as needed.
Teach speech recognition service about attribution
chains. If an implementation does nothing the OS
would enforce permisisons and do blame as always.
This apporach leads to double blaming and doesn't
support attribition chains where app calls into
the default recognizer which calls into the on
device recognizer (this nests recursively). If the
implementer takes advantage of the attribution chain
mechanims the permissions for the entire chain are
checked at mic access time and all apps are blamed
only once.
Fixed a few bugs around finishing ops for attribution
chains. Also ensured that any app death in a started
attribution chain would lead to finishing the op for
this app
bug: 158792096
Test: (added tests for speech reco)
atest CtsMediaTestCases
atest CtsPermissionTestCases
atest CtsPermission2TestCases
atest CtsPermission3TestCases
atest CtsPermission4TestCases
atest CtsPermission5TestCases
atest CtsAppOpsTestCases
atest CtsAppOps2TestCases
Merged-In: Ic92c7adc14bd2d135ac13b96f17a1b393dd562e4
Change-Id: Ic92c7adc14bd2d135ac13b96f17a1b393dd562e4
Modern f2fs implementations starting in S support compression
natively within the file system. The data blocks of specific
installation artifacts [eg. .apk, .so, ...] can be compressed
at the file system level, making them look and act like any
other uncompressed file, but consuming a fraction of the space.
However, the unused space is not free'd automatically. Instead,
we must manually tell the file system to release the extra
blocks [the delta between the compressed and uncompressed block
counts] back to the free pool.
Because of how compression works within the file system, once
the blocks have been released, the file becomes read-only and
cannot be modified until the free'd blocks have again been
reserved from the free pool. For these installation artifacts,
that is not a concern.
Test: atest CtsAppSecurityHostTestCases:SplitTests
Test: atest CtsAppSecurityHostTestCases:IsolatedSplitsTests
Test: atest CtsAppSecurityHostTestCases:PkgInstallSignatureVerificationTest
Test: atest CtsLibnativehelperTestCases
Test: atest PackageManagerTests
Test: Manual. Boot the device and see cblocks for stub APKs are released
Test: Manual. Disable and re-enable stub APK and see cblocks are released
Bug: 188928405
Change-Id: I4b29dab263d02a79d7b1593d35ae28101d33679a
Avoid most floating content by centering the requested content within
the view instead of just scrolling so that it's visible.
See ag/14213766 for the corresponding RecyclerView change.
Bug: 189487659
Test: atest ScrollViewCaptureHelperTest, plus manual testing.
Change-Id: I194288cf9e568614ffd7c45b7d046a5b982829d6
This changes the screen off animation so that the controller directly animates the LightRevealScrim and the shade keyguard UI, rather then tying these to the dozeAmount. This makes it easier for us to manage/cancel these animations, such as during the camera launch gesture, since the various doze components update their state asynchronously.
This approach also means that instead of actually changing everything to KEYGUARD as soon as the power button is pressed, we actually just show the LightRevealScrim and the shade's AOD UI. This results in far less jank. We then actually show the keyguard once the animation finishes or is cancelled.
Bug: 169693662
Bug: 169739682
Bug: 181020504
Fixes: 185567665
Fixes: 189342687
Fixes: 185567665
Fixes: 183195436
Test: atest SystemUITests
Test: trigger screen off and cancel it
Test: trigger screen off and don't cancel it, make sure it wakes up fine
Test: disable 'power button locks instantly' and make sure it doesn't lock the device, both when the animation finishes or when it's cancelled
Test: press the power button twice in rapid succession
Test: press the power button twice in slower succession about 200ms apart (which triggers the camera onWakingUp vs onFinishedGoingToSleep)
Test: press the power button 5 times, make sure emergency gesture comes up
Test: disable AOD, observe no screen off animation and lock functionality works
Change-Id: I1c44304becdadfd37bab7fd81286a9702e5d6141
* Instead of resolving colors as-needed, resolve the entire palette potentially used by the notification at the start.
* Centralize color logic and palette storage into Notification.Colors for easier unit testing.
* Adds unit tests for the Notification.Colors, including validating color contrast ratios for various colors.
* Fix a bug with ColorContrastUtil where the luminosity for dark/light font cutoff was 0.5, which resulted in a max contrast ratio of 1.9 for some colors. Now contrast ratios of 4.5:1 can be achieved for all colors.
* Removes a few of the color accessors in Notification.Builder which were infrequently used, and replaces them with direct use of Notification.Colors.
* Notification specific colors (primary, secondary, default) have only been used by colorized notifications for a few months. Remove the dark mode overrides of these, ensuring that colorized notifications have the same exact appearance in light and dark themes.
* Replace the use of the "default" color with the "secondary text color"; this practically only affects the alerted bell icon, is more consistent, and reduces complexity.
Fixes: 187881776
Test: manual
Test: atest android.app.NotificationTest
Change-Id: Ib8840d04093094c324d8bdce5b2e84c93a94db8d
