Use ParcelFileDescriptor only as an IPC transport
to make sure MemoryIntArray manges its backing fd.
Bug:30310689
Change-Id: Ib3cc13ef4ae2a744e5f7a96099570e0431847bce
(cherry picked from commit fe2462f3a60b34ee6b7d8764d92ae58fc0cd7dfd)
After removing updates for a system package, we weren't updating its
shared libraries when we should have. Make it so.
NOTE: This didn't affect device boot because we update all of the
shared libraries for all system applications after scanning packages.
Bug: 30266503
Change-Id: I8edf4344228fb3e793e7648ea70a041cb5db6af6
(cherry picked from commit 6058df65e645a81bdc7285dcd9f8b12b9f5b534f)
The following changes are in this commit:
Avoid destroying TextureView surfaces for onStop
bug:30238922
TextureViews will hold onto their backing surfaces, which will allow
them to resume gracefully when the app's surfaces are saved.
Now only resources that are destroyed for onStop are DisplayLists.
(cherry picked from commit 391d560402c2902e0fd701f99eabd91025154201)
TextureView: destroy layer on destroyHardwareResources event
bug:30468770
(cherry picked from commit 1c16c37d8646ed25e844af8472eede988ad0c2f0)
Fix NPE in TextureView
Bug: 30651595
(cherry picked from commit 3c2587f26eed32a8723488131d1d8940dc147ee1)
Fix NPE in TextureView
Bug: 30779663
(cherry picked from commit 7e237189c292cdb886733eb95c6069b7ac002527)
Fix maps resume being blank
Bug: 30889568
Fixes an issue where mLayer didn't have
the mSurface set on it in certain resume
scenarios.
(cherry picked from commit 03df0834e63b587dbfb8fdcd0086e3e1e72b9f9d)
When multiple alarm clocks are scheduled at the same time, we would
flap among the alternatives for considering them the 'next upcoming
alarm clock', which in turn would generate [many] spurious broadcasts
about changes to the upcoming alarm situation. This is now fixed;
once we have found the soonest upcoming alarm clock, we stick with
that one until it becomes unavailable, eliminating the spurious
broadcast traffic.
Bug 29501073
Change-Id: Ice1892490bb339e05fa8bd9d324fa1c6718b4942
(cherry picked from commit 76389c00d3d3ce79e48d9e87b597707ed3e8970c)
This CL explicitly checks if we're finishing activity in non-focused
stack as there are other cases except this one when we finish paused
activities in FINISH_AFTER_VISIBLE mode.
Bug: 29007436
Bug: 29458854
Change-Id: I67744d23cd72f2fe8861180008bfdd284a7b5e26
(cherry picked from commit 995fa2bd2d334a37e10760c21ac108f4a3595713)
This CL fixes an edge case that my previous CL [1] forgot to handle.
The goal of my previous CL was to avoid InputMethodManager from getting
confused by a false focus-in event from temporarily detached Views.
However, my CL forgot to take care of the case where the temporarily
detached View is still focused even after the temporary detach mode is
done.
The bad news is that such a situation is relatively easy to trigger by
having a ListView that has EditText as follows, which seems to be
known to be a common technique in Android developer community to put an
EditText in a ListView.
ListView#listView.addHeaderView(new EditText(context), null, true);
If the ListView is initialized as above, and the EditText has input
focus, View focus and IME focus start to disagree immediatelly after the
ListView's layout is re-evaluated. This is really easy to trigger, for
example just by dismissing the IME window.
In summary, the root cause is that InputMethodManager#focusIn(View) is
now always ignored as long as the View is temporarily detached, under an
assumption that IMM#focusIn(View) will be called back again with a View
that is not temporarily detached when everything is stable. Hence the
fix is to do so by hooking up View#dispatchFinishTemporaryDetach() to
call IMM#focusIn(View) again when the View is actually focused in the
final state.
[1]: Ia79bbd8468f768d546354382b47b39dd31ef7bb5
a4ed0cfcb6885beeb52f701bfc64c393b668f7ba
Bug: 30022872
Bug: 30578745
Bug: 30706985
Change-Id: Iecbdb00dcef8c72e4f7b31035c9bf0f4a40a578f
(cherry picked from commit dd228fbb4d2cb3d178ed7f1889343bfe177aafa2)
Don't allow the status bar icon slot list to be changed because
it confuses the relationship between StatusBarIconList and
StatusBarIconController. Set it in the constructor to enforce
this.
Change-Id: Ieeea0a9efad88179d1cccc0e5702899333de2e72
Fixes: 28524184
(cherry picked from commit c6fe61c59c5a3a6ae691256c9afdde3820e3dd9e)
AlertDialogLayout overrides LinearLayout#onMeasure but not onLayout,
meaning that some state initialized for the handling of gravity may
not be valid in LinearLayout#onLayout. As this is an internal class
never used directly by apps, explicitly specify the default gravity of
start|top in @layout/alert_dialog_material to avoid this bug. Apps
that do things like set gravity in their theme (for whatever reason)
could otherwise change its behavior.
Bug 30494039
Change-Id: I71a8be1829a7fe24cf7714a3bd5ed732f85eb887
(cherry picked from commit 39e0bf23f50a3de112b232321c5e0a1013af70c7)
Symptom:
When sharing an image from Album, ChooserActivity can be shown.
But then the app to be located to the bottom part of the list may not
be started even if user tap it.
Root cause:
ChooserActivity uses ResolverDrawerLayout. And ResolverDrawerLayout
can display only some items on the list (known as "Collapse mode").
When the item clipping along the bottom edge is tapped by the user,
ResolverDrawerLayout tries to expand the list and scroll it to a
better position, instead of starting an application.
In this problem case, ResolverDrawerLayout continues to try to expand
the list whenever tapping, so an application will never start.
Solution:
Change a condition so that mOpenOnClick becomes true only when the list
has been collapsed (mCollapseOffset > 0).
Bug: 30153542
Change-Id: I576fb6c8b6a91d79c1e0d46d069146779f4dbd17
(cherry picked from commit 4f3a843ea9b6ffe2e29e6625ffb3d87fbf143623)
Use application context to get the screen's display metrics.
Bug: 30127070
Change-Id: I2c453c494ef210c12d89fc7e3ff026728f9ecb0f
(cherry picked from commit afb38c5cc4226ce82367015f4ce52765018226d6)
View attachment calls jumpDrawablesToCurrentState(), so the view state
needs to be set up prior to attachment. For views that are already
attached but are being moved to a new position, manually jump.
Cleans up comments in methods that were modified.
Bug: 29978498
Change-Id: Ica27b2c60ad7ee98b9d1e4912c4f8b8c248af88d
(cherry picked from commit 26489e1688633ee270ff1469d0df38c90bbdf674)
With sensitive notifications a user could get into
a situation where the groupsummary would not be cleared
because its dismissability was never updated and based
on the visibility of the veto button. This is now corrected.
This Cl also cleans up the veto button handling overall and
ensures that there's no stale state arond it.
Change-Id: Ic7df8d382146d7863ee551c1daa8ba5ed384c7b5
Fixes: 30056258
(cherry picked from commit 9e624e732aa5646c83d203587be9c2c4e94c9266)
When activity is finished we first looked for next activity to
show in focused stack. If real next activity to show in place
of finishing one is in the same non-focused stack, we didn't
fully complete the dismissal process and activity was stuck in
FINISHING state.
This CL checks if we're trying to finish visible activity in
paused state and destroy it immediately if top running activity
is visible - same as we do for pinned activities.
Bug: 29458854
Change-Id: I0d5ceb2daa45c0628d89417c8456e132996bcea9
(cherry picked from commit 7318d63ba6dbb3042907d10d5369fcd5ac444d67)