- Allow recents component to enable/disable layer tracing
- Expose flickerlib classes for use with sysui/launcher tests
- Allow trace files to be moved to a path that the client can read
- Ensure layers are flattened with depth traversal to encode ordering
Bug: 140244969
Test: atest FlickerTests
Change-Id: I7af5699ff5b8a4bc62c1a8105c67b31bc45a2236
Merged-In: Ia0934ec7c2b9484fa6c85f5aa8d9b2e5e6f7dc0f
To prepare for enabling MissingNullability Metalava check this CL
works on adding missing nullability issues that metalava flags if
we tell it to flag new things since API 29.
This is not a complete CL, mostly addresses public api and
toString/equals for @SystemApi
Exempt-From-Owner-Approval: Large scale nullability clean up
Bug: 124515653
Test: make -j checkapi
Merged-In: I109260842cfc25f06e40694997fcbb4afa02c867
Change-Id: I109260842cfc25f06e40694997fcbb4afa02c867
- Moved exclude filters to existing stanzas
- Removed new stanzas added w/ filters
- Removed un-needed filters because existing "include-filter"
already excludes failing tests.
Disabling in preparation for merge to aosp-master (Q release).
Disabling the following tests:
FrameworksCoreTests:android.view.textclassifier.TextClassifierTest#testSuggetsConversationActions_deduplicate
CtsAppTestCases:android.app.cts.ServiceTest#testAppZygoteServices
CtsAppTestCases:android.app.cts.SystemFeaturesTest#testLocationFeatures
CtsProviderTestCases:android.provider.cts.MediaStore_Images_ThumbnailsTest
Test: Forrest
Exempt-From-Owner-Approval: Disabling known failing TEST_MAPPING tests
for AOSP push to Q.
Change-Id: I4dc2408c5bc6d421654f871c5d63d402c1d96d91
Some apps rely on not updating the window format when changing the
background of the DecorView. To keep the compatibilty with these app we
add only call DecoreView.drawableChanged() when the window background is
changed on app targetting Q and above.
Test: Manually test by lunching Instagram TV and pressing return twice.
The window should aninate with no flickering.
Bug: 136987724
Change-Id: I3593d30dc6f10519008151974e475f0dad86fc64
(cherry picked from commit 843f9dee8b)
When the WindowManager lock is contended, reportSystemGestureExclusionChanged can cause
jank. Making it oneway avoids this.
Fixes: 137650591
Test: make droid
Change-Id: I5d96b7e2225745b146014ad11cafaf0ad9a1b734
Merged-In: I5d96b7e2225745b146014ad11cafaf0ad9a1b734
(cherry picked from commit e6911497de)
In Q, these APIs were either:
- removed from the greylist entirely without good reason
- Moved to the restricted greylist without any public alternative
information added
So they are being moved back to the greylist for Q.
Test: Treehugger
Bug: 136102585
Change-Id: Ie3dd15c8e17d530d853473a013717e6175383080
... as throwing an exception in there somehow will mess up the
hwui task queue.
Test: Have a crashy app, swipe up while the app is crashing
Fixes: 134583193
Change-Id: Ie3ba5f991759f807b154f55f9fc816e7efe2fdfe
As discussed in https://r.android.com/973723
This makes any camera key event wake up the device.
Handling of the camera key apart from waking up the device might follow
in a later commit.
Signed-off-by: Felix <google@ix5.org>
Change-Id: I44dbc3f9ac465f664b6d740cb6a056b7f6e118fb
When the configuration changes between landscape and reverse
landscape, the app will not receive onConfigurationChanged as
orientation is not part of the public portion of the configuration.
However, when the ViewRootImpl receives such a configuration back from
relayout, it will force a layout of the client views
(see updatedConfiguration in performTraversals), this is because
Configuration#equals compares the non public part of the configuration
as well. This CL changes MSG_REPORT_RESIZED to handle the configuration
changing the same way performTraversals does, so that the app consistently
receives a configuration change.
Bug: 134643273
Test: Manual
Change-Id: If016bcd9a5b8d2a7efc5e1ab3c82a88a608caf8b
Annotates InputMethodSystemProperty#MULTI_CLIENT_IME_ENABLED as @TestApi
to let cts can verify if multi-client IME enabled.
Bug: 135217809
Test: build and passes
Change-Id: Id7b4dceb2dbfaf3d7ed1084957dd14b04cad0cdf
... as opposed to strong references.
In case the calls between register and unregister aren't matched, we don't want to be leaking views.
I haven't seen any real eveidence of there being leaks, just a report. But this is preventative.
Created a "WeakSparseArray", which wraps SparseArray, and passes in a kind of WeakReference that has an id.
The references become unreachable, we use the id to remove the the entry from the SparseArray.
Test: Used the device for a bit with talkback on. CTSAccessibility*
Change-Id: I8d11727428f56fc06007232ae341d1409a11991f
Fix: 134506015
failed to launch app resolver when there are more than one app handlers.
What happened:
1. TextClassifier constructs an implicit intent to fulfill a task
like opening a link, making a phone call, etc.
2. TextClassifier calls resolveActivity against the implicit intent to
resolve the intent. The resolve component name will be used to create
an explicit intent. In this case, the intent is resolved to the
app resolver activity.
3. wouldLaunchResolverActivity in SysUI returns false for an explicit
intent with component name android/ResolverActivity.
4. SysUI does not trigger the "start the activity after the keyguard
is gone" logic because wouldLaunchResolverActivity returns false.
5. When user clicks on the action on keyguard, ResolveActivity.onStop
is triggered because it is shown (and thus moved to the background)
under the keyguard. So, finish() is called in onStop, and thus the bug.
IMHO, wouldLaunchResolverActivity should not return false
for an explicit intent with component name android/ResolverActivity.
But since we are late at this point, the safest option is to not setting
component name when the intent is resolved to package "android". Note that
this is what we are doing for P, so it should be pretty safe.
Test: 1. Install two browsers. Send myself a link. Tap on the Open Link
chip on keyguard. App resolver is shown.
2. atest frameworks/base/core/tests/coretests/src/android/view/textclassifier/
BUG: 129220155
Change-Id: I6d4d67c2233a2fec950887ea274825bf1cbc1ae2
Currently, updateBoundsSurface was getting called when the surface
changed, not just when the size changed. This meant it could be calling
setWindowCrop and deferTransaction when no size had changed. If size
hadn't changed, there was a high possibility that no new frames would be
submitted by the client, causing the deferTransaction to wait forever.
Since the deferTransaction was still waiting, SurfaceFlinger would wake
up every vsync to check if it should call doTransaction for the deferred
transaction. This caused 60Hz composition even when frames were rendered
slower.
Fixes: 132110524
Test: SF doesn't compose 30fps app at 60Hz
Change-Id: Icf3a99b34c288575438bfcd05e9077ea7919b4ca
Fixes an issue where we would measure WRAP_CONTENT windows inconsistently
in the measure passes before and after relayoutWindow.
Fixes: 119839070
Bug: 73813813
Change-Id: I376e416d648f31a0dedecd6a70b476c3bf82b8b0
Test: Install test case app from 119839070, verify dialog is correctly laid out.
for logging in the default TC.
TCEvents for selection and links are not currently being written to
default TC logs. This changelist writes these events as SelEvents.
Bug: 131228248
Test: atest android.view.textclassifier.TextClassifierEventTest
Change-Id: I191f2f9281eab1b8a427ef21717fff283a304a22
