When it is happening:
a) Disappear Visibility transition is applied to the recyclerview(and it's children)
b) Transition added the View to the ViewOverlay for an animation
c) Transition is first paused before being canceled (for example when the new reversed transition wants to start after user click)
d) In Visibility.onPause() we call suppressLayout(false) for RecyclerView
e) RecyclerView starts layouting and tries to use our view, but it is currently added to the overlay
f) So it crashes on attempt to call addView
Fix: Detach a view from overlay in Visibility transition while it is paused. Attach it back in onTransitionResume if the view is still not used by someone else like RecyclerView.
Bug: 33609996
Fix in AndroidX: I18d8327b338be442ec30b15fe53a99d1a2974888
Test: cts tests for Transitions
Change-Id: I74f138617c8afbac9f6efa4ee9a1f4e961306c9e
The perf regression found in my initial attempt [1] to instantiate
InputMethodManager (IMM) for each display revieled that when a Window
gained/lost focus,
getContext().getSystemService(InputMethodManager.class)
gets called for all the View objects that belong to the Window.
This CL introduces a private utility method
View.notifyFocusChangeToInputMethodManager()
to replace existing unnecessary acquisitions of IMM in View.java,
including the most concerning one View.onWindowFocusChanged().
There should be no negative side-effect in doing this optimization.
LatencyTests results:
testExpandNotificationsLatency on taimen-userdebug
without this CL:
results=[43, 46, 58, 47, 52, 59, 55, 59, 58, 46]
min: 43.0, max:59.0, avg:54.7, median:53.5, std_dev:5.967
with this CL:
results=[41, 58, 55, 59, 60, 67, 51, 55, 55, 55]
min: 41.0, max:67.0, avg:55.6, median:55.0, std_dev:6.344
[1]: I7242e765426353672823fcc8277f20ac361930d7
c53d78e992
Bug: 115893206
Test: atest ActivityManagerMultiDisplayTests
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Test: atest FrameworksCoreTests:android.view.inputmethod.InputMethodManagerTest
Test: No perf regression observed in Bug 117434607
Change-Id: I5c64b23c3f5cb16f7f3fb9cdc2be063083566050
This CL implements the biggest chunk of launch bounds logic in Android
branch and combine ActivityLaunchParamsModifier logic into
TaskLaunchParamsModifier. It left some things to be implemented:
1) It didn't yet consider persisting/recovering data;
2) It didn't implement letterboxing/pillarboxing, but according to
offline chat this should be enforced after launch bounds policies by
system;
3) Immersive mode is not yet implemented, but that's more tied to
recovering previous immersive mode and we won't launch apps to immersive
mode directly in any case;
4) No last seen non-fullscreen bounds are set if display is fullscreen,
which could be useful when display windowing mode changes from
fullscreen to freeform at later time.
There are also some topics that for sure need future discussions, so I
left them out of this CL as well:
1) App controlled apps (not only bounds specified in ActivityOptions);
2) Metadata indicating that the app prefers tablet-like bounds for
freeform windows (i.e. w/o limiting window size to Nexus 5x screen
size);
3) Fixed maximized size, which indicates that the maximized size
shouldn't be changed due to display resolution or orientation changes;
4) What to do if app requests to launch an activity without any flag
that indicates a new task should be used, but with a preferred display
ID/bounds set to a different value than its current window;
5) Should insets be considered in launch bounds (AM side) or on WM side,
IIUC freeform windows don't need to consider insets, and fullscreen
windows are covered by WM.
Our policy also has special treatment for Chrome snapped windows
(side-by-side mode in our tablet), which may not make much sense in
Android.
Bug: 113252871
Test: go/wm-smoke. Try launching some freeform windows on secondary
displays.
atest FrameworksServicesTests:TaskLaunchParamsModifierTests
atest ActivityManagerManifestLayoutTests
Change-Id: I974031725015b6283f33b9076788e7ce45134690
Test: UT and manual
atest .../LooperStatsTest.java
Verified that adb shell cmd looper_stats dump produces data
with dispatch delay
Bug: 113651685
Change-Id: I44550f8c5d71848932733bd02016aa65ce7b75b3
Require NETWORK_SETTINGS (or NETWORK_SETUP_WIZARD) instead of the
legacy CONNECTIVITY_INTERNAL permission. The users are as follows:
- The system callers (Phone, Settings, SystemUI, VrSettings) all
have NETWORK_SETTINGS.
- SetupWizard has NETWORK_SETUP_WIZARD
- sl4a has NETWORK_STACK
Bug: 115302596
Test: builds, boots, airplane mode via SystemUI works
Change-Id: I8ca40182bd8b5e3fd9a82296c0cc28de30ed4baf
A lot of unresolved link errors showing up after go/ag/5172152.
Test: m -j docs with -lerror enabled
Bug: b/116163454
Change-Id: I74d1f75e0f00015410a63e13103c28a9c84b4fe0
