Fix a concurrency issue when we might start activity enter transition
animation from an unprepared layout which caused ocassional visual
artifacts.
Fix: 232963730
Test: Manual testing by launching Chooser with varius intents.
Change-Id: I3962250b53ea8d96b124d1daf964e447600a5e3a
May 2021 HCT code in Android ("CAM") gives results inconsistent with
HCT in design tooling. Using HCT solver ensures they match, allowing
design to verify their specs against the results in Android, derisking
the launch of theme variants.
HCT Solver is a standalone class that is easily integrated with Android
& Cam: when Cam.get(hue,chroma,tone) is called, it now calls
HctSolver.get(hue, chroma, tone).
HCT Solver was imported from google3, where it is tested against _all_
hex codes, both forward and reverse conversions. A number
of other tests cover all parts of the theming system, giving us high
confidence that there won't be a regression.
Test: atest ColorSchemeTest (unit test); atest SystemPaletteTest (CTS).
Spent ~4 hours trying a variety of wallpapers, and seed colors, and
used dumpsys to verify results match UX spec. Verify hex codes and HCT
values output by Android match those in design tooling via putting
hex codes into Monet Studio, and confirming the resulting HCT values
match the HCT values generated by Android.
Bug: 213314628
Change-Id: I95da1efacc2d61f19ce7f20efa3e7f70736258a9
When the TextView takes up multiple lines, the layout acts as if the
full width is used, thus pushing the pin all the way to the left.
This change measures the text itself and computes an ideal width for the
TextView based upon the line measurements.
Test: Visual inspection: pin several targets: single line, first line
longer, second line longer, etc. Observe spacing.
Bug: 232445263
Change-Id: Id7601c58aae1e28c66c5311ba66b288443d73272
When recreating the Activity, if the window is preserved,
onAttachedToWindow won't be called and PhoneWindow.onViewRootImplSet
won't be called either, where we set the actual dispatcher to the
Activiy's proxy dispatcher.
So when the window is preserved, we directly assign the actual Dispatcher
from the preserved Window to the new PhoneWindow
Fixes: 228571903
Test: In progress
Test: Open an app with OnBackInvokedCallback enabled, split to top,
close the other application, do a back gesture
Change-Id: I050247501df8f6cf6cd0024a6233f88a035f6279
With the `ResolverDrawerLayout`-`RecylerView` combination it was
possibel for accessibility navigation to get off-screen.
The issue is addressed by adding a custom accessibility delegate to the
recycler view which makes sure that an item receving accessibility focus
becomes visible.
Bug: 230132993
Test: Manueal - user accessibility navigation on the Chooser with a long list of
apps; make sure that items that receive a11y focus become visible when
scrollng in both directions.
Change-Id: I448d88660f701ca3c5ea0c92416595c9389af521
We're hoping to gut the recycling code in the messaging notification
code entirely (it's a lot of complexity for apparently little or no
performance gain), but in the meantime, mitigate a System UI crash.
Bug: 231025249
Test: none, I found no unit tests to start with
Change-Id: I3bcc14d102a87ed96ce37241d25eccf44ba2acb0
The PopupWindow will show up above the anchor with the real rectangle.
If the anchor is doing an animation, it will get a temporary top of the
anchor because the rectangle is conisince changed by the animation. So
attach tooltip after a while for waiting the animation is done.
And when the tooltip overrides the inline suggestion, clicking the
suggestion won't work. Force the y offset above or below the anchor to
fix the problem.
Bug: 223088398
Test: atest android.autofillservice.cts.inline.InlineTooltipTest
Change-Id: I068efc3d20f4486decd2c9e690ebeb2981fb6722
- Handling the case that all languages in the suggestion list
- Adding strict condition for reusing convertView in getView()
Bug: 233175025
Test: Verified with test apk
Change-Id: I9419704226322394125e495bd9a35a5edd0683e8
Previously tabs were full-width, now they align with the outer edges of
icons.
In ResovlerActivity, this is constant. In ChooserActivity, the placement
of the icons is based upon the icon count and layout width, so it must
be computed at runtime.
Bug: 233330219
Test: Manually with various orientations across Chooser and Resolver.
Test: atest ResolverActivityTest, atest ChooserActivityTest
Change-Id: I2009211c277f6ea0b3f14a06a54e82f4c190c564
As we're resetting it right after that, it doesn't make sense to
explicitly remove it.
Bug: 233563626
Test: atest ProcStatsValidationTests
Test: atest ProcessStatsDumpsysTest
Test: atest CtsIncidentHostTestCases:ProcStatsProtoTest
Change-Id: Ibd12379a7678a60238af79f86e694e1dc3c97176
Define instrument constant in InteractionJankMonitor
TODO(b/232176881):
Instrument in Biometric code in next CL.
- AuthContainerView transit in : SHOW
- AuthContainerView transit out : DISMISS
- AuthCredentialView transit in : SHOW
- AuthCredentialView transit out: DISMISS
- AuthBiometricView transit(Biometric <-> PIN/Password/Pattern): TRANSIT
Bug: 232176881
Test: atest SystemUITests
Test: make and get perfetto trace
Change-Id: I17fb2b5e00005c611efe2342abc30196ae4ccc31
Active MediaProjection cannot be tracked using AppOps,
instead this uses MediaProjectionManager callbacks to track the
corresponding new PrivacyType.
Bug: 184629645
Test: atest AppOpsPrivacyItemMonitorTest PrivacyItemControllerTest PrivacyConfigFlagsTest
Test: m SystemUI CarSystemUI ArcSystemUI
Test: Manual on TV, observe media projection privacy indicator
Change-Id: I8924ebb7871da432b0e4e49c465a0c43e515ca4b
Merged-In: I8924ebb7871da432b0e4e49c465a0c43e515ca4b
There was an error where if two auto-brightness changes came in quick
succession, the first could be treated as a user-initiated brightness
change.
1. First float change comes in: Xf
2. We write the brightness to the int-setting: Xi
3. Second float change comes in: Yf
4. Notification of the Xi change comes back to us and because X is
different from Y, we treat it as a user-change.
The result of this is that auto-brightness learned from these erroneous
"user inputs" and both the short and long term model get affected
negatively for the user. Often manifesting in brightness learning to
be too low.
The quick succession changes can happen in various situations, but
were most prominent on startup before and after a valid lux is read.
The fix is the revamp the data synchronization algorithm we use in
BrightnessSynchronizer to have updates + confirmation callback be
treated as an atomic operation before executing any other updates
that come in. In the example above, that means we run (1) (2) and (4)
before handling the new update found in (3).
Fixes: 227483176
Test: Manually verify through debug logging.
Test: atest BrightnessSynchronizerTest
Change-Id: I93856fd74e50bcda04e88a7b7e736e02faa76c8e
