| Age | Commit message (Collapse) | Author |
|---|
|
Refactored the directory structure so that services can be optionally
excluded. This is step 1. Will be followed by another change that makes
it possible to remove services from the build.
Change-Id: Ideacedfd34b5e213217ad3ff4ebb21c4a8e73f85
|
|
|
|
timeout while finish Activity"
* commit '46f618a7d9dde8e668666e0c582d88ddfea759d9':
Keydispatching timeout while finish Activity
|
|
If there is input to be handled during finish activity we can get a
keydispatching timeout ANR. The reason is that finish activity is some
times not possible, and the activity is instead put on a finish queue.
The activity will then be finished sometime in the future. When we add
the activity to the finish queue, key dispatching is paused, and there
is an ANR timer waiting for it to be resumed again. Since it can take a
long time before the activity is actually finished, we need to resume
the key dispatching to avoid the ANR.
Change-Id: Icea4ab3b5ad05c8bfbadf8f5cece1a59ec621469
|
|
- Introduce concept of ActivityStacks residing on Displays and able
to be decoupled and moved around.
- Add a new interface, IActivityContainer for clients to handle
ActivityStacks.
- Abandon ordering of stacks based on mStackState and instead use
ActivityDisplayInfo.stacks<ActivityStack> ordering.
Progress towards closing bug 12078972.
Change-Id: I7785b61c26dc17f432a4803eebee07c7415fcc1f
|
|
move back in ActivityStack."
* commit '38bcf6dc8784625eb4b68634450c578719346669':
Fix to NullPointerException on move back in ActivityStack.
|
|
In ActivityTask.moveTaskToBackLocked NullPointerException may occur
when moving back with only current Activity in stack. This due to a
condition that may trigger despite a TaskRecord being null and then
attempt accessing the TaskRecord.mOnTopOfHome variable.
TaskRecord task may be set to null when no resumed activity remain.
Resolved by assuring that flag mOnTopOfHome is instead set to false
for current TaskRecord in case where there are no remaining activities
above home.
The above bug has already been corrected in the following commit,
ada62fca51d314cefe2c5da4e007df5b9abf320d, but it does not set the
cottect value to mTopOfHome for the current taks, see below.
Variable mOnTopOfHome will not be set to false in situations where
stack is of size 1 or less and task is null, perhaps from already
having finished current activity.
To avoid current TaskRecord maintaining value mOnTopOfHome to true
after launching Home this variable is set to false.
Impact should not be major due to correction earlier that makes sure
that there is always a TaskRecord.mOnTopOfHome set to true above Home
activity but if not correctly set for current task still gives a
possibility of bad behavior.
Change-Id: Ie86ad99c188aaa05b0de9d58eaa16c42b6fc4341
|
|
When Intent.FLAG_ACTIVITY_REORDER_TO_FRONT was set the TaskRecord
member frontOfTask was being set true incorrectly for the top
activity. It should only be true for the bottom activity. This fix
ensures that frontOfTask is always set correctly for all activities by
consoldating it into one method.
Fixes bug 12171535.
Change-Id: If982dad3c81b2b816adc5d89e7e0496923098a70
|
|
Not needed since java.util.Objects implements all the needed
functionality.
Change-Id: Icd31d49a9801d1705427f028e9ac927d58e7d34c
|
|
|
|
Fixes bug 11673948.
Change-Id: I60b590b9793ae1b8d5c3d343f4bb6cb40ba4a092
|
|
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
|
|
klp-dev
|
|
...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
|
|
Fixes NullPointerException bug 11432611.
Change-Id: I62e765750e2613ecfb79e13021631ed2cd4e79f3
|
|
Unless they are in another task.
Fixes bug 11374158.
Change-Id: I961d4ce9520bc84a182806db2ccb072501c8357a
|
|
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
|
|
settings.
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
|
|
|
|
Change-Id: I5d7c11e8b8525bfc8eb87bb0fff4f71337b4a39d
|
|
Only the activity stacks were being restored. Also add needed debug
logs.
Fixes bug 11223831.
Change-Id: Ief42688721c49e8cea14277619c797bf7c25b859
|
|
|
|
setLaunchTime() was only being called from resumeTopActivityLaunched()
but also needed to be called from minimalResumeActivityLocked().
Fixes bug 11104901.
Change-Id: I35c994562dffaf75de014021c775e398224eb3a3
|
|
|
|
Fixes bug 11198896.
Change-Id: I7b35c8a7156f03f8dab0598b55ef327e593f6427
|
|
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
|
|
|
|
|
|
into klp-dev
|
|
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
|
|
Change-Id: I0517ccd9a83ef19a9002d61dbebf36d0120e1f63
|
|
- Call in all circumstances but only set launchHomeTaskNext for
focused stack. Previous version didn't call handleAppDiedLocked for
non-focused stack.
- Rearrange logic to run down the top task and make sure that all
remaining activities belong to the dying app. Previous version just
looked at the top non-finishing activity and based its behavior on
that.
Fixes bug 11029560.
Change-Id: Ic3a7c873c4c975577d6b390a8955ff41729bdfde
|
|
Fixes jank exposed in 10881705. Specifically background activity
animating up along with translucent activity. Repro steps on manta:
1. From home start Settings.
2. Press home.
3. From home start Downloads (translucent activity that takes 85% of
screen).
4. Observe that as Downloads zooms up the 15% boundary that should be
dimly transparent are showing Settings.
The cause was that there is a finishing activity in the Downloads task
that was used to launch the DownloadsActivity. The existence of that
activity kept the logic from recognizing that the home activity was
behind the DownloadsActivity, not the Settings activity.
This fix descends through all of the activities in a task sitting on
home and makes sure that they only keep home from showing if such
activities are not finishing and visible.
Change-Id: I607afce6b0000b4db634f2ce40a6c37fcee369d7
|
|
|
