* changes:
Move Wu check for max colors earlier.
Ignore transparent pixels during WSMeans
Fix create colors in Wu quantizer
Fix initializing clusters with random randoms
As requested, mount was added to OWNERS for RecyclerView
and ViewPager as changes are occasionally needed by UI
toolkit team.
Test: None
Change-Id: Ie3d49d0d5ddf092d2dd0680c6a067b2fe6b81f94
This has no impact. However, after going through the quantizers line by
line for other bug fixes, after getting a break from looking at them
in-depth for a couple weeks, it was much more readable/felt safer to
adjust mMaxColors at the top.
Bug: 182333325
Test: Verify output remains constant,
atest CtsAppTestCases:android.app.cts.WallpaperColorsTest#fromDrawableTest
passes.
Change-Id: I561ba44bca392634a956992fd946f3310aa1c8ee
The WSMeans quantizer uses starting clusters from a Wu quantizer as
starting points for an optimized Kmeans algorithm.
The first thing the quantizer does is assign pixels from the image being
quantized to those starting clusters. Either due to the image source or
downscaling, transparent pixels may be in the pixels. Filter those out:
they create misleading results, such as there being two colors in the
image, semi-transparent black and green, in a wallpaper that is solid
green by all accounts.
Fixes: 182333325
Test: atest CtsAppTestCases:android.app.cts.WallpaperColorsTest#fromDrawableTest
passes locally on sunfish. link: http://ab/I26300007868608112
Change-Id: Icaebd98eeba27d3dc59a698282dd3be03fce1bf9
This line is suspiciously complicated compared to other 3 ints -> int
representing color functions. This patch ensures the colors produced
have an explicitly opaque alpha channel (transparent pixels are filtered
out earlier in the quantization process), and ensures we're not
unnecessarily masking the red/green/blue channels.
Test: Add log dump to output hex for all colors created, immediately
after the Wu quantization finishes, thus isolating it from the larger
quantization process. Test a variety of wallpapers, make sure hex codes
make sense, verify that the fix holds by converting
Bug: 182333325
Change-Id: Ic0bd4afcd095845e00eb6d10d05aab336266d6c3
During the quantization process, an instance of a Quantizer is created.
When quantization is run, the Quantizer may need to create starting
points that are random. To keep results stable, meaning multiple runs of
a quantizer output the same results, those starting points must
be created using a Random with the same starting seed. Without
specifying a starting seed, or if an instance of Random is reused across
runs, the random starting points will vary across quantizer runs.
With this patch, the Random used to create starting points is no longer
used across multiple runs (i.e. it isn't a static variable anymore).
Additionally, a starting seed is specified.
Test: Add log dumps after the quantization process. Verify that results
from Kmeans remain consistent as long as the input is consistent.
Bug: 182333325
Change-Id: Ia0f984349b7885ae1b44536aaa1b286a28e50587
We didn't end the trace section in FrameTracker#cancel if the end
vsync id equals to the begin vsync id which is not an invalid value.
This cl fixes above problem.
Bug: 181683700
Test: atest FrameworksCoreTests:InteractionJankMonitorTest
FrameworksCoreTests: FrameTrackerTest --iteration 10
Change-Id: I6280e9b1e9b949cb6f144217ed78d21ec46eafd5
This CL reworks our previous CL [1], which enabled "adb bugreport" to
include wintrace tracing files into bugreport.
In the previous CL there was a side-effect that wintrace tracing files
are saved not only when "adb bugreport" is executed but also when the
following command is manually executed.
adb shell dumpsys window --dump-priority CRITICAL --proto
This is because we used the combination of
--dump-priority CRITICAL
and
--proto
as a signal that it's coming from "adb bugreport", but strictly
speaking it's not necessarily true.
Instead of relying on such a heuristic, this CL introduces a claer and
dedicated command as follows.
adb shell cmd window tracing save-for-bugreport
With this, we can let "adb bugreport" trigger the above command to
make the behavior more understandable and maintainable. Note that
this command is no-op when winscope is not running.
See the corresponding CL for frameworks/native [2] about how it's
triggered from "adb bugreport".
Our main motivation of this consolidation is to use the same pattern
for IME tracing, where we accidentally introduced Bug 177462676 while
attempting to save IME tracing data while running "adb bugreport" [3].
[1]: I102bc4afab5efff361633d75c09af1df4a11812e
9e2604688d
[2]: I8be9dee9aa36c2b085596d58e418f8613d874500
95305b3ba7bf18bc7ed3a07c67f84b1c2f4586f4
[3]: Ie87eb8423e2bb70f28c330983d45b95e2e07062d
ac24994aaa
Bug: 177462676
Test: Manually done as follows.
1. adb shell cmd window tracing start
2. adb logcat -d -s WindowTracing:*
Make sure wintrace is not yet running
3. adb shell dumpsys window \
--dump-priority CRITICAL --proto > /dev/null
4. adb logcat -d -s WindowTracing:*
Make sure wintrace has not been stopped.
5. adb shell cmd window tracing save-for-bugreport
6. adb logcat -d -s WindowTracing:*
Make sure wintrace was stopped then restarted.
7. adb root && adb shell ls /data/misc/wmtrace/ -al
Make sure wintrace files are saved.
Test: Manually done as follows.
1. adb logcat -d -s WindowTracing:*
Make sure wintrace is not yet running
2. adb logcat -d -s WindowTracing:*
Make sure there is no additional message
3. adb shell cmd window tracing start
4. adb logcat -d -s WindowTracing:*
Make sure wintrace is running
5. adb bugreport bugreport.zip
6. adb logcat -d -s WindowTracing:*
Make sure wintrace stopped then restarted.
7. unzip -v bugreport.zip | grep wm_trace.pb
Make sure "wm_trace.pb" is included.
8. unzip -v bugreport.zip | grep wm_log.pb
Make sure "wm_log.pb" is included.
Change-Id: I887ae6941b4844a606675b447f67ecee88d7f192
This is only necessary when a notification is posted without a title.
Fixes: 177976174
Test: Manual inspection of various staes.
Change-Id: I15fdc31e1557b7e5d6fb99e410f4bf37d6734ac4
Use the same approach that is used to track system server thread group
CPU usage: KernelSingleProcessCpuThreadReader which uses the eBPF
time_in_state program to record CPU usage for selected pids and tids.
Test: cmd stats pull-source 10098
Test: atest CpuStatsTests
Bug: 181232205
Change-Id: I84d46409547f92e410fd3b4f8b8ccb823bcee98b
Handle onConfigurationChanged() in order to prevent restarting
InputMethodService everytime. We introduce a new API attribute
"configChanges" in InputMethod(attrs.xml) which when declared
by IME, will be responsible for handling mentioned
configuration changes.
This CL re-introduces [1] with fix: Use new Configuration instance for
IMS#mLastKnownConfig
[1] Iff88b768c6b06cf5cf1fe9e97ee97f8f78e6f0bd
Bug: 167948419
Test: atest InputMethodServiceTest
Manually:
1. Patch Ie91e7a8e06b80864ef9409031e8543858552d70d to use dual
display area.
2. Open applications with editors on both display areas.
3. Attach a debug point for IMS#onConfigurationChanged().
4. Make sure IMS#resetStateForNewConfiguration() is not called
when IME moves between these two identical DisplayAreas
Change-Id: Ib94fddadb0dae648cf73a4c1642e51edebd19f50
We didn't remove the observers if the cancel invocation came from end(),
this caused leakage of FrameTracker, so we always remove the observers
no matter where the cancel invocation comes from.
Bug: 181683700
Test: atest FrameworksCoreTests:InteractionJankMonitorTest
FrameworksCoreTests: FrameTrackerTest
Change-Id: Ia03ebc3b579257dd387eaa1be65b9d22e7b7bf91
This uses a new system API to attribute the source package when copying
to clipboard from the share sheet.
This is needed because in S users will see a toast message saying
"<app> pasted from <source>" when an app accesses clipboard. Without
this change, any copy originating from the share sheet results in
"<app> pasted from Android System" rather than the app that is the
actual source of the data.
Bug: 180577866
Test: Manual, share via share sheet and paste in another app;
observe "<app> pasted from <source app>"
Change-Id: Id1c0afcf6e775868febc7c8ab5b44dbacccacfa2
In this patch, we change the behavior to trigger the hotword
detection service when the interactor application calls the
new "createAlwaysOnHotwordDetector" function. The system will
also pass the read-only data(Ex : model data) back to hotword
detection service by using the share memory when the service
is initialized.
So the interactor application can use the new function with
share memory to pass the model data back to hotword detection
service.
Bug: 176938619
Test: atest CtsVoiceInteractionTestCases
Change-Id: I753988691725c9d962be25c92d60ec66a3812394
When the legacy PhoneStateListener was migrated to the new
TelephonyCallback class, the onCallStateChanged listener was copied over
as is. This CL removes the phone number parameter from the new listener.
Under the hood, both the old PhoneStateListener and the new one use the
same IPhoneStateListener.aidl file, so the onCallStateChanged method for
the legacy listener is changed to onLegacyCallStateListener.
Test: See CTS test CL; added a bunch of CTS tests for this.
Fixes: 165831812
Change-Id: Ia67968b5235954b606c6bd2890cc6f46c468e041
* changes:
SysUI changes for setSuppressBubble
Track locusId visibility in ShellTaskOrganizer
Add locus id to ActivityRecord / TaskInfo
Bubble API: suppress bubble
As these objects/lists could be mutated after being dispatched.
Bug: 181193693
Test: atest BatteryStatsBinderCallStatsTest BinderCallsStatsTest
Change-Id: I9de44e734acc7313d03ee616aa5e2f0a01da7cf3
Track battery voltage along side the measured energy to calculate
battery charge consumption per EnergyConsumer. This better represents
a consumer's impact on battery. Also change numerous variable/method
names from energy units to charge units.
Bug: 180079165
Fixes: 173765509
Test: atest FrameworksCoreTests:com.android.internal.power.MeasuredEnergyStatsTest
Test: atest FrameworksCoreTests:com.android.internal.os.BatteryStatsNoteTest
Test: atest ScreenPowerCalculatorTest
Test: atest FrameworksServicesTests:com.android.server.am.MeasuredEnergySnapshotTest
Change-Id: I5e727cebf1252cc7b1645a53282de2281c68ae85
To measure end-to-end touch latency, we need to report the actual
present time to ViewRootImpl. ViewRootImpl, in turn, will report this
information to InputDispatcher. Finally, InputDispatcher will combine
all known information for a specific input event, and will report this
data to westworld.
In another patch, we will add a new call, 'reportLatencyInfo', to
InputPublisher. This call will allow the app to send this latency data
to InputDispatcher.
Bug: 169866723
Test: printed the input event present times inside ViewRootImpl
Change-Id: Ibd3a2cfeb1a340eb15cd2165071df1f8589634af
