* commit '1fbb5da29a4ebef1d758dffad9c2704a5932d223':
Fix a JNI local reference leak in JNIMediaPlayerListener::notify.
Add null pointer check.
Import translations. DO NOT MERGE
Small DocumentsProvider doc improvements.
Keyguard isn't visible if it hasn't been drawn.
Enable fast camera transition when launched from navbar
Reduce camera launch time by about 250ms.
camera2: Remove prior repeating request when setting.
If a window claims to handle its own configuration change then we
won't destroy and recreate its window on a configuration change.
Normally that recreation triggers the first layout following
orientation change because mHaveFrame is false. Windows that handle
their own configuration changes never got a relayout pass following a
change in orientation.
This change passes the configuration changes that an application
handles into the AppWindowToken. If the app says it handles
orientation or screen size changes then a relayout will occur when the
configuration has changed.
Fixes bug 11647107.
Change-Id: Ie8d49fd050442ebbdcf0b805087894e3a2fc4be9
When the home activity launches a non-fullscreen activity as part of
its own task then ensureActivitiesVisibleLocked() must continue past
the launched activity when determining activities to show and hide.
Stopping at the non-fullscreen activity leaves the fullscreen home
activity hidden.
Fixes bug 11555762.
Change-Id: I9058d8cde3a41cb7f9b1f97e5c0cb32e9b0f5af7
The method ActivityRecord.setTask() removes the ActivityRecord from
its old task's mActivities ArrayList. In jb-mr2 it did not have this
side effect (there was no mActivities) so calling it twice was not a
problem. This fix causes setTask to only be called once for the target
activity.
Fixes bug 11557835.
Change-Id: If2b6d4b297e86130009713efe6891a24fad3dd15
One cannot iterate across an entire list if one both removes an entry
and increments the index into the list. Do one or the other or you
will end up with bugs like 11556768 which is now fixed.
Change-Id: I57f1ad13075a005cae3c1cbfae10e230d9af143a
Previously inserted requirment that an activity be visible in order to
block visibility of the home screen is removed.
Fixes bug 11515761.
Change-Id: Ia47cfb4a0b6d90bbbca2b42e12a6048b1644d7cb
...not to work on KitKat (was: Janky exit animation)
Reworking the LRU list (splitting it into an activity vs. empty
section) accidentally broken the old behavior of "client activity"
processes being prioritized with activity processes. In fact, we
were no longer marking "client activity" processes at all.
In this change, we rework how we manage "client activity" processes
by putting them on the main activity LRU section. This is generally
simple -- ActiveServices now keeps track of whether a process is
a "client activity" process based on its bindings, and updateLruProcess
treats these as regular activity processes. However, we don't want
to allow processes doing this to spam our LRU list so that we lose
everything else, so there is some additional complexity in managing
that list where we spread client activity processes across is so
that the intermingle with other activity processes.
The rest of the change is fairly simple -- the old client activity
process management is gone, but that doesn't matter because it wasn't
actually running any more. There is a new argument to updateLruProcess
to indicate a client process it comes from (since we now need to update
this based on bindings) which is just used to limit how high in the
LRU list we can move things. The ProcessRecord.hasActivities field is
simply removied, because ProcessRecord.activities.size() > 0 means the
same thing, and that is actually what all of the key mechanisms are using
at this point.
Finally, note there is some commented out code of a new way to manage
the LRU movement. This isn't in use, but something I would like to
move to in the next release so it is staying there for now for further
development.
Change-Id: Id8a21b4e32bb5aa9c8e7d443de4b658487cfbe18
Activities launch starting windows before they are resumed. If another
activity is started after a first activity has launched its starting
window then it was possible that the starting window will never be
removed. An earlier fix, ag/368411, solved this by posting a delayed
message that would remove orphaned starting windows after 10 seconds.
This fix immediately removes starting windows that have been orphaned
through the above sequence.
A few code cleanups are also included in this CL.
Fixes bug 11029212.
Change-Id: I7a9befca92888aefe4000b90716c57c2aa572634
When a non-fullscreen task over home launches another non-fullscreen
task then the home task might not be displayed. Looking all the way
down the task stacks until reaching a visible, fullscreen activity or
home provides the right information.
Fixes bug 11273803.
Change-Id: I8dab0956c1cda06ddb7850ea3ffac7f6a223c6ad
When finishing or stopping an activity the code was automatically
refocusing to the next activity on the same stack independent of the
task's onTopOfHome flag. When the activity eventually finished or
stopped it would then honor the onTopOfHome flag.
This fix examines the onTopOfHome flag and arranges the focus
correctly if home is the next activity to run.
Fixes bug 11318263.
Change-Id: I73a8f5e82de04b01acaffe366b085f9e475e1451
Two problems addressed here:
- If a call to startActivity() comes in on an activity that is finishing, we can
end up putting the new activity in a stack that isn't actually in use any more
(if the finishing activity is the last one on that stack). This is a bad case,
anyway, so if this happen the treat it as not being called on an existing
activity and switch to NEW_TASK to find a task for it.
- There was a bug in handling PACKAGE_CHANGE broadcasts that would result in the
app's processes being killed, even though the cleanup through the activities
was done. This could leave the activity stack in a bad state. Fix this to
correctly provide an app id for the changing package so that its processes are
killed.
Change-Id: Iece04e0cf95025c3d30353d68bf3d14fd39d44c3
setLaunchTime() was only being called from resumeTopActivityLaunched()
but also needed to be called from minimalResumeActivityLocked().
Fixes bug 11104901.
Change-Id: I35c994562dffaf75de014021c775e398224eb3a3
The CL that ensured that a dying task must be in front of the user
(ag/374996) only checked that the task was at the top of /a/ stack,
not on top of the frontmost stack. This checks the stack for being
frontmost before switching to home.
Fixes bug 11208762.
Change-Id: I43f6d380e7a880ec19db03711ada6c7437e15f73
The previous fix that returned to home when a task on top of home was
removed was too broad. If that task was not the foreground task it was
not a good idea to bring the home screen to the front.
Fixes bug 11198552.
Change-Id: I14e5fdc167011f25e0e8490c3e52c5c1dcbffbff
Killing an app that was launched from home was not relaunching home.
Previous situations relaunched the next app (i.e. home) based on the
task flag. However, when an app dies the relaunch is deferred until
the TaskRecord has long been forgotten. This fix rearranges the stacks
immediately upon the TaskRecord being removed from the stack. Then the
next resumeTopActivities() call will start the home task.
Fixes bug 11189555.
Change-Id: I0e09350a7db55ea8b38cce7bf4b69923a6b99494
Screenshots were not being made for tasks with the flag
FLAG_EXCLUDE_FROM_RECENTS set. But if the task is in the foreground
the shot should be taken even with the flag set. This fix adds a test
for tasks being in the foreground.
Fixes bug 11170567.
Change-Id: If42db7f43ed1dd8d2b16b68824adc813b31c94f0
When a dialog has been minimized to recents the windows behind it
won't be visible. Yet we were requiring them to be visible in order to
be included in the ones being restored. This left the background
windows invisible on resume and showed home behind floating dialogs
instead of the activity that launched the dialogs.
Fixes bug 11067724.
Change-Id: Icadd7ec8fe7c73b52982b6ff5b5d98b8fb8476b0
Trying to span all potential stacks looking for apps was too complex
and error-prone. Extending the jb-mr2 method across multiple stacks.
Fixes bug 11080696.
Change-Id: I6391ceae4ad6a0955a409c3fb27472219fd5bf6b
If the last screenshot activity is resumed, we need to always capture
a new screenshot, because it can change at any time.
On the other hand, never create a thumbnail for tasks that have set
themselves to not show on the recent tasks lists, since we have no
use for them.
Change-Id: I38523afc966c125da93339e0100da950119cdf99
Remember which stack was in front when the user changes. Restore that
stack when the user changes back. Remove user state when user is
deleted.
Fixes bug 11068986.
Change-Id: I18dfbc35a0c2e21e7a4024227cbfc5ba1208b3a3
Localize the point where it is determined whether a task should sit on
top of home or return to the task below it.
Fixes bug 11080913.
Change-Id: I79d1ea9722c867d6b550ddfcd1db35517a79cd90
Bug: 10918599
Reduce the number of recent tasks to 10 on lowram devices
Use RGB_565 on low ram devices for thumbnails instead of ARGB_8888
Combined this saves ~9MB across system_process and systemui
Change-Id: Ieddcb512c7341a90097bc7cbc72d7355a775b416
