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 391d560402)
TextureView: destroy layer on destroyHardwareResources event
bug:30468770
(cherry picked from commit 1c16c37d86)
Fix NPE in TextureView
Bug: 30651595
(cherry picked from commit 3c2587f26e)
Fix NPE in TextureView
Bug: 30779663
(cherry picked from commit 7e237189c2)
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 03df0834e6)
Before there was a jump-cut when a window that was occluding Keyguard
was going away, leading to an ugly flicker. To fix this, we do the
following.
- Always show windows with FLAG_SHOW_WHEN_LOCKED above lockscreen, even
if they don't "match" the currently occluding app (which is null in the
animation case)
- Move wallpaper behind last window that is not hidden by policy, so the
window doesn't get occluded by the wallpaper.
- Add a flag in the setOccluded call whether to animate or not. SystemUI
then plays a nice animation when it's set.
- Override the animation to always be the animation that happens when we
exit a window which is revealing the wallpaper behind, to make it
consistent with the home screen case.
Fixes: 30829255
Change-Id: Ib3fe20fc9003a0f9f291c974740f044ed8707e75
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 76389c00d3)
If an activity was launched in the docked stack and we weren't able
to retrace the launch back to an activity launch from the homescreen
in activity manager, nothing happened.
Now we try to do a better job by also checking some conditions when
the app transition is starting. Note that this might still be racy,
but in practice all activities are usually launched from the same
process so the app is done starting/finishing any activities when
the first frame is drawn, so we are able to catch the correct state
when we figure out that the app transition is starting.
In addition to that, we also need to not hide the docked stack while
lockscreen is showing. This doesn't make any sense anymore as we are
dismissing the docked stack when we show something above the lockscreen,
and this only lead to issues that triggered app visibility events
which triggered this special unnecessarily. This also fixes some flicker/
race-condition in the normal unlocking process I noticed a long time ago
but couldn't really reproduce.
Change-Id: I42683520ba9ee9fbd0c9920501387a573ac94655
Fixes: 30439313
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 995fa2bd2d)
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
a4ed0cfcb6
Bug: 30022872
Bug: 30578745
Bug: 30706985
Change-Id: Iecbdb00dcef8c72e4f7b31035c9bf0f4a40a578f
(cherry picked from commit dd228fbb4d)
As a minimal risk improvement for Android N, we allow a new
load/unload transaction request to cancel a currently pending
one if enough time has passed since starting the current
transaction.
Bug: 30111539
Change-Id: Ide958c2454b88529305443fb789b8ae5af18c642
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 c6fe61c59c)
Use %zd for size_t. Note that this will break only on (-plus-)aosp because
clang is disabled on the N development branches.
bug: 30963384
Change-Id: I4b5ba7caf15bc2ebf5bb3395d82170ec786ed50c
We don't want these descriptors to be shared post-fork, so we'll
have to close and reopen them when the zygote forks. The set of
open descriptors is checked against a whitelist and it is a fatal
error if a non whitelisted FD is opened. It is also a fatal error
if anything other than a regular file / character device or socket
is opened at the time of forking.
This work is done in two stages :
- An initial list of FDs is constructed and cached prior to the
first zygote fork.
- On each subsequent fork, we check whether the list of open FDs
has changed. We are currently tolerant of changes, but in the
longer term, it should be a fatal error if the set of open file
descriptors in the zygote changes.
- Post fork, we traverse the list of open descriptors and reopen
them if necessary.
bug: 30963384
Change-Id: Icfd45c96c660491b554d146a9d70d97dbcc712bc
Sometimes we switch away from a network to another (e.g., wifi to
cell data) not because the old network is unvalidated, but
because the score is lowered by a low signal strength.
In this case, don't notify the user of a network switch.
Bug: 31132499
Change-Id: I996a6e00096f8cb864fa9b00b36921725a4edb53
NetworkPolicyManagerService (NPMS) used to depend on screen on/off
changes to determine if a foreground activity should have network
restrictions, but such check is now redundant since ActivityManager
already changes the proper UID state (like going from TOP to
TOP_SLEEPING) when the screen status is changed.
Removing such code decreases the NPMS lock contention when the screen is
turned on in about 3-5ms.
Change-Id: I2853443efedbf14961ae9a5b2e72689d4d1a646c
BUG: 30785671
(cherry picked from commit 88f40ad9a7)
(cherry picked from commit f8dd7b4e8d)
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 39e0bf23f5)
