If extraction is run on a set of pixels whose count is less than the
number of max colors, then colors.length < max colors, and accesses
to colors[index] inside the for loop throw an ArrayOutOfBoundsException.
Test: add widget to home screen, reduce size of widget to small area.
observe crash. `mp core services` with fix, observe that crash no longer
occurs. `mp core services` again without fix, verify crash occurs after
boot.
Fixes: 181130209
Change-Id: I60bf1ab39f7a69f2fb0745049fd46d2f0b53a12c
This change includes a series of API review changes. The most
significant update is the addition of cancellation signals to
API methods where needed.
Renames some internal classes and interfaces to support the
API changes and to simplify tests and improve quality.
Test: numerous presubmits
Bug: 175830670
CTS-Coverage-Bug: 180419562
Change-Id: I9b1b950a2779fc902ecf4d6394e3c35171926700
Creates presubmit test mapping for BatteryStats-related
files.
These tests can be run manually via
atest FrameworksServicesTests:com.android.server.am.BatteryExternalStatsWorkerTest FrameworksServicesTests:com.android.server.am.MeasuredEnergySnapshotTest FrameworksServicesTests:com.android.server.am.BatteryStatsServiceTest FrameworksCoreTests:com.android.internal.os.BatteryStatsTests
Tests that currently fail are marked to be skipped;
they should be addressed by b/180015146.
This is accomplished by introducing a new annotation, @SkipPresubmit.
Test: treehugger presubmit
Bug: 180016384
Change-Id: If01beaa342468aeded660e5766a14391d3ee9bcc
The parameter was always true (it was a remnant of a previous
approach).
Test: atest FrameworksCoreTests:com.android.internal.power.MeasuredEnergyStatsTest
Bug: 174818228
Change-Id: I3be5392966c3455b2df145044809a581abbf245c
The PositionUpdateListener in BackgroundBlurDrawable is called from
a thread pool to update the position of the BlurRegion. After that,
in frame drawing callback (RenderThread), the Aggregator takes all
the settings in BackgroundBlurDrawable and dispatches them to SF.
However, while the RenderThread is working on frame N, the Ui thread
is working on frame N+1. So when the frame drawing callback is
called on RenderThread for frame N, BackgroundBlurDrawable
might already be holding settings for frame N+1.
In this CL, we fix that by making BackgroundBlurDrawable work only on Ui
thread, while BlurRegion lives only on RenderThread. Just before
drawing, we copy the state of BackgroundBlurDrawable into a BlurRegion.
So when render thread starts doing its thing for frame N, Ui thread can
start setting up BackgroundBlurDrawable for frame N+1. The settings for
frame N are already copied over to BlurRegion. In frame drawing
callback, we take the blur regions if there is a pending update and send
them to SF.
Bug: 167166562
Test: m && atest BlurAggregatorTest
Change-Id: Icec0fa8e97de30b7bad15b97f848ae642076652f
Rename the apis to be more consistent.
Also expose to test api.
Have the aosp mark that it supports the toggle features by default.
Test: atest CtsSensorPrivacyTestCases
Bug: 162549680
Change-Id: Ib38c16adfc5cec931347e1a1891618983d78248b
It is possible for old uids to be reported to BatteryStats
in updateCustomMeasuredEnergyDataLocked().
This can happen, e.g., if a uid was uninstalled between
successive custom energy updates, so that the uid did use non-zero
energy but BatteryStats doesn't care anymore since the uid is gone.
If this happens,
we don't want to recreate any removed Uid objects, so we need
to be careful to only consider Uids that aren't removed.
In practice, this method will only be called after the CPU update,
which means that BatteryStats should already know about all active
uids (assuming they used CPU). Therefore, there shouldn't be any
unknown uids actively using custom energy buckets at this point.
We therefore simply ignore any unknown uids (just log them), on
the assumption that they refer to removed uids or stopped users.
Test: atest BatteryStatsTests
Bug: 180030409
Change-Id: If4fee7a1d11b148ca16d464d6ce4720c5a251130
Revert "[sysuig] Integrate Monet color extraction to theme algorithm"
Revert submission 13554372-kahuna
Reason for revert: Colors on some wallpapers shifted, and Lucas found a couple big reasons why, would rather revert a revert tomorrow than fix forward today
Reverted Changes:
I2c3df9f71:[sysuig] Integrate Monet color extraction to theme...
I0fc60a134:[framework] Integrate new quantizers
Change-Id: I7eb8e4fde243bf62e8c750f88028db0a427560b5
Do not return to Java mode between consecutive fork operations.
This greatly reduces the Zygote overhead, since we no longer need to
stop and restart Java daemons.
By not switching back to Java mode, and being careful about what memory
we touch between forks, we also keep the Zygote heaps much more stable,
facilitating page sharing between the zygote and all its children.
Under normal operation we should no longer allocate any memory in the
zygote between forks. That applies to both the Java and C++ heap.
This makes the zygote behave much more like the mental model many
of us had assumed: It has nearly constant memory contents, which are
copy-on-right cloned at each fork. This does not apply to the initial
system server and webzygote forks, that are currently still handled
differently.
This includes
1. Add ZygoteCommandBuffer, and switch the argument parsing code to use it.
This slightly reduces allocation and enables (3).
2. Support process specialization in the child, even when the arguments
are already know, Leverages existing Usap code.
3. Add support for forking multiple child processes directly to the
ZygoteCommandBuffer data structure. This directly uses the buffer
internals, and avoids returning to Java so long as it can handle the
zygote commands it sees.
FUNCTIONALITY CHANGE:
We now limit the total size of the zygote command, rather than the
number of arguments.
Initial performance observations:
[ These are not perfect, since I'm comparing to numbers before I
started. There may have been other moving parts, but they should be
minor. ]
System-server-observed launch latency:
[Not the best metric, but easy to measure. In particular, this
does not represent a significant reduction in application launch
time.]
Based on measuring the last 10 launches in a lightly used cf AOSP
instance, the system server latency from requesting an app launch to
response with the pid (which does not require the child to execute
anything) went from an average of about 10.7(25) msecs to 6.8(9) and
7.9(16) in two tries with the CL. (The parenthetical numbers are
maxima from among the 10; the variance appears to have decreased
appreciably.)
Dirty pages:
The number of private dirty pages in the zygote itself appears to have
decreased from about 4000 to about 2200. The number of dalvik-main
private dirty pages went from about 1500 to nearly zero.
Initially ART benchmarking service claim -1.88% in PSS. But this is not
consistently repeatable.
Drive-by fix:
Call setAllowNetworkingForProcess on usap / native loop path.
Bug: 159631815
Bug: 174211442
Test: Boots AOSP
Change-Id: I90d2e381bada1b6c9857666d5e87372b6a4c1a70
