| d23dc17754f1ef1416f4dfb36c9226626113f08c |
|
13-Dec-2016 |
Svetoslav Ganov <svetoslavganov@google.com> |
Add Bluetooth toggle prompts - framework
am: b1e2da7c24
Change-Id: I29c038d23488c504c838a85bd97c255b84919aab
|
| 9fff53f2cb9cdd5b830ff61f174a1b356c82de51 |
|
12-Oct-2016 |
Shunta Sato <Shunta.Sato@sonymobile.com> |
Avoid NPE around mReusedTask of ActivityStarter
Symptom:
System crash by NPE is observed on ActivityStarter
during phone boot-up.
Detail and sample:
ActivityStarter has possibility to be called itself recursively
by calling TaskRecord$performClearTaskLocked().
Then class variable of mReusedTask is initialized to null
after the call, because the recursive call isn't guarded by
synchronized block.
Then NPE crash occurs on next statement.
Solutions:
Call performClearTaskLocked() before assigning
intentActivity.task to mReusedTask.
Bug: 32361138
Test: builds, boots, Manual testing of condition in bug
Author: Shigeki Yokomichi <shigeki.x.yokomichi@sonymobile.com>
Change-Id: Iaea3e066a6f7134fcae4338ff864bb236241194c
(cherry picked from commit 0bd28e2c5f7fd7e4448ae489b425e4e5cee57f9a)
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| b1e2da7c24613ce393bca871069d379cd4378c26 |
|
30-Jun-2016 |
Svetoslav Ganov <svetoslavganov@google.com> |
Add Bluetooth toggle prompts - framework
If permission review is enabled toggling bluetoth on or off
results in a user prompt to collect consent. This applies
only to legacy apps, i.e. ones that don't support runtime
permissions as they target SDK 22.
Also added a configuration resource which controls whether
permission review mode is enabled. By default it is not and
an OEM can change this via an overlay. For now we also keep
the old mechanism to toggle review mode via a build property
which is still used and will be removed when clients have
transitioned.
bug:28715749
Change-Id: I94c5828ad6c8aa6b363622a26ff9da4fc2e2fac7
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| f73d0853953198945b905695c93e562209a861c5 |
|
23-Nov-2016 |
Anthony Hugh <ahugh@google.com> |
DO NOT MERGE: Properly set FLAG_ACTIVITY_BROUGHT_TO_FRONT for onNewIntent() callback
It looks like there was a regression where #onNewIntent() was called
before the FLAG_ACTIVITY_BROUGHT_TO_FRONT flag was set. This
change updates the code so we set the flag properly.
BUG: 33034247
Change-Id: I61959a289dc5af14ee9d3d7bfa213191238efc88
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| 52f179fd0eebf6452b2ab2844cfe83bd3ec356b8 |
|
22-Sep-2016 |
Todd Kennedy <toddke@google.com> |
Pass url to the AIA supervisor
The supervisor needs the URL in order to start the correct AIA.
Change-Id: Ied9b50031b31f6da07196efbccbb27cacda1355f
Fixes: 31664252
Test: manually ran through ephemeral scenario
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| 32daa7a95cd49cbedf00c006cf80929518cc5465 |
|
08-Sep-2016 |
Robin Lee <rgl@google.com> |
DO NOT MERGE Stop work challenge freeform bypass am: 0737c2b4c2
am: ec5ceae174
Change-Id: Ic4bbce08944881f0d20a08c1ebb4db5531208f23
|
| ec5ceae1743b64822cb7ca35d5938109a8beb370 |
|
08-Sep-2016 |
Robin Lee <rgl@google.com> |
DO NOT MERGE Stop work challenge freeform bypass
am: 0737c2b4c2
Change-Id: Ia76391f710e42e9634010bd211a0370230b318e3
|
| c8cccdcbd3ea8511b17d58ddbdc4a15e440f7f89 |
|
31-Aug-2016 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Fix bug that apps are not unminimizing if recent tasks are empty" into nyc-mr1-dev
|
| 936aaeb8781e55e988578e7c8b19e973a37b50f1 |
|
27-Aug-2016 |
Jorim Jaggi <jjaggi@google.com> |
Fix bug that apps are not unminimizing if recent tasks are empty
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
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| 0737c2b4c2ae6415eced00926235f848d1957bae |
|
08-Aug-2016 |
Robin Lee <rgl@google.com> |
DO NOT MERGE Stop work challenge freeform bypass
Bypassing work challenge in freeform mode was trivial by just keeping
work apps open in freeform mode and then switching focus to them from
another app.
Because the only interception point is startActivity this never
triggered work challenge.
The solution is to trigger the check on focus change events and also to
allow passing the result back into the freeform stack instead of dumping
our user out into the homescreen.
Change-Id: I141ecf90b5f0e708a21d27141b6fec6074e5d475
Fix: 30693465
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| fea1b776e96d10879769d3a3c17f297146605062 |
|
28-Jun-2016 |
Todd Kennedy <toddke@google.com> |
Implement new ephemeral resolver design
In the new design, the ephemeral installer can be returned from
queryIntentActivities which means any intent resolution could potentially
return the installer. Additionally, the new design calls for a platform
defined broadcast receiver that receives the status from the ephemeral
installer. This receiver then starts the final intent -- either to launch
the ephemeral application or to launch the fallback.
For more detail, see go/ephemeral-design
Bug: 30805203
Bug: 30273584
Change-Id: I6644bbb4f180d2d22c63af04b9857577516344a9
(cherry picked from commit 8e2d9d1d9050e93b15c54e992698325c7d4aa57c)
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| d67b187dcc5bde21ef9c137529ade4d375f13d4c |
|
22-Jul-2016 |
Makoto Onuki <omakoto@google.com> |
Fix realCallingUid/Pid for startActivities()
They now match startActivityMayWait().
Bug 30277795
Change-Id: I883d74bf02cb79a19e2139134aa9be0296787fed
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| fc20505e37f9986b7ecc5eaa337d3a49a1db265e |
|
01-Jul-2016 |
Andrii Kulian <akulian@google.com> |
Merge "Don't update task to return to type for last task over home" into nyc-mr1-dev
|
| dc0f8933da69f7d462bf256f34f5e9d6dab653f5 |
|
29-Jun-2016 |
Andrii Kulian <akulian@google.com> |
Don't update task to return to type for last task over home
Resizing docked stack to fullscreen size results in dismissal of
docked stack and moving of tasks to fullscreen stack. When tasks,
which were originally launched from home or recents, are inserted
on top of fullscreen stack, their mTaskToReturnTo value was
overwritten.
This CL doesn't allow to overwrite this field of task if there is
no next task in stack and it was launched from home or recents.
Also this reveals issue b/29342752. When app is moved to PiP mode,
system UI shows another overlay activity in separate task in PiP
stack with hint to user. In ActivityStarter#startActivityUnchecked
some logic assumes that new activity is launched from focused stack.
But PiP stack is not focusable, so we end up thinking that overlay
activity was launched from home stack. This sets mTaskToReturnTo of
overlay task to HOME_ACTIVITY_TYPE instead of
APPLICATION_ACTIVITY_TYPE.
This CL checks if stack id is specified and checks preferred stack
if available instead of currently focused one.
Bug: 29237751
Change-Id: I3a55b84d6a57be758705db51dec60592683e4e02
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| d82efd36dc43f2136212703debc7b48814b1e55f |
|
23-Jun-2016 |
Andrii Kulian <akulian@google.com> |
Merge \"Don\'t compare intent filters on singleTask adjacent launch\" into nyc-dev
am: 42147f0ff3
Change-Id: Ie767b54e2622a823d8e2fe2a864d788c3a81df74
|
| 039ba48973733b7ca5573ac3ee1eb36341d61ecd |
|
23-Jun-2016 |
Andrii Kulian <akulian@google.com> |
Don't compare intent filters on singleTask adjacent launch
Bug: 29578845
Change-Id: Ic1614fc1f321e80ffdc2ab498d720657f393c239
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| 6098085ababfc54455c32832fe5034838c975769 |
|
22-Jun-2016 |
Chong Zhang <chz@google.com> |
Merge \"Unblock \'am start -W\' if activity is brought to front without launching\" into nyc-dev
am: 75c7cc6ca9
Change-Id: I983331f65f03d50c26b7929866e3ce5d5ae19966
|
| 5022da313f6b2fbd16e55ebabaadbb308e96e908 |
|
22-Jun-2016 |
Chong Zhang <chz@google.com> |
Unblock 'am start -W' if activity is brought to front without launching
If -W is used to start an activity successfully, but this activity just
brings another activity to front without actual launching, the waiting
will be stuck because neither activity will report launch complete.
In this case, we have to treat it as if the -W started an activity and
received return code START_TASK_TO_FRONT. It needs to wait for the new
activity to become visible (or report launch complete if it's already
visible).
This reverts earlier commits afb776d5447e19565c9a826a554911decb9ed92a,
since it's causing problems with launch time reporting.
bug: 28333487
bug: 29451567
Change-Id: I9fd79ab5b3ed8f9de5df34ed9c7b0be3a94620b2
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| b809d1cb79b065443a1d8e19b2d5685c7c3383bd |
|
21-Jun-2016 |
Andrii Kulian <akulian@google.com> |
Merge \"Compare intent filter when launching adjacent\" into nyc-dev
am: 9980514ee0
Change-Id: I8c2b03438fdeed6bce12489c5639245b79097577
|
| d3bbb13fe29e8b6c931497daeb124669e050b419 |
|
17-Jun-2016 |
Andrii Kulian <akulian@google.com> |
Compare intent filter when launching adjacent
When we're looking for a task during adjacent launch, we need to
perform full intent filter comparison instead of just comparing
components.
Bug: 29424577
Change-Id: I10f271986a8dc405e28a053e4cb122c1e9aa6ee0
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| ddfeb4a6c2bc97250619175a281746344e7c40d2 |
|
16-Jun-2016 |
Andrii Kulian <akulian@google.com> |
Merge \"Bring task to front when we can\'t move to adjacent stack\" into nyc-dev
am: 320c15e1b2
Change-Id: Ia0732370e4952d5cbecfb4ed86150eba090fbb49
|
| ad6f2e580f783d5d320d3265bd617adedf55c944 |
|
16-Jun-2016 |
Andrii Kulian <akulian@google.com> |
Bring task to front when we can't move to adjacent stack
If task was requested to move to adjacent stack with mLaunchStackId set
and FLAG_ACTIVITY_LAUNCH_ADJACENT not set - we don't move it from its
current stack. If the task was covered with other task(s) it wouldn't
be brought to front.
This CL checks if mLaunchStackId is provided and is a valid stack for this
task, then we move it to front of current stack as a safer option.
Bug: 29103549
Change-Id: I3065960f082cfbf9a5b43c6e83b5cebe3dd69df6
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| bf914699d5e24c1eeccd4f687eaa18b84ad1940d |
|
09-Jun-2016 |
Andrii Kulian <akulian@google.com> |
Merge \"Don\'t update mTaskToReturnTo when task is cleared\" into nyc-dev
am: 1a77efe9ba
Change-Id: Idb9aad2fb3161552b699f271bed940cb47fd98ad
|
| 4b7f2d46be85700b9f1d90c9986a13cc2453156c |
|
09-Jun-2016 |
Andrii Kulian <akulian@google.com> |
Don't update mTaskToReturnTo when task is cleared
If activity launch has moved other task that was over home while
clearing task - don't override its mTaskToReturnTo not to loose
the original value of other task.
Bug: 28986980
Change-Id: Ib1680769fbb8a8d99f2b210c8d9cd8fe6fd5a196
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| a4e2bf471221162347d6489d5422f7127860a191 |
|
08-Jun-2016 |
Wei Wang <wvw@google.com> |
Merge "Add launch power hint for activity launch end" into nyc-mr1-dev
|
| 65c7a15833b61bf2a3d193992326a68716f0aca4 |
|
03-Jun-2016 |
Wei Wang <wvw@google.com> |
Add launch power hint for activity launch end
This change will provide more accurate duration for launch power hint
Bug: 28220567
Change-Id: Ie620b6ce93c72f21b5a6ef2604892bb751b045f3
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| f4b91fe3e18b98e575cf498a5fdbcd8ad9603ce1 |
|
03-Jun-2016 |
Andrii Kulian <akulian@google.com> |
Merge "Fix task selection logic" into nyc-dev
am: 265bd89c3c
* commit '265bd89c3cb6f99d38d2f126a88c12fc6502431c':
Fix task selection logic
Change-Id: Ic80d782ca53d8cf7a565a9337a686441edbd2c72
|
| 265bd89c3cb6f99d38d2f126a88c12fc6502431c |
|
03-Jun-2016 |
Andrii Kulian <akulian@google.com> |
Merge "Fix task selection logic" into nyc-dev
|
| 02082ad6317d1b53c35b8e6239d4c41dedd5533a |
|
03-Jun-2016 |
Jorim Jaggi <jjaggi@google.com> |
Merge "Fix unminimizing dock stack for AppTask.moveToFront" into nyc-dev
am: 6321f42fbe
* commit '6321f42fbee425745de9636d45e4973fa6c470b9':
Fix unminimizing dock stack for AppTask.moveToFront
Change-Id: I82b844611cb1761a681f91e2e26b25308202c6da
|
| 206b9faa09ada62ce07026301723805b687e9892 |
|
02-Jun-2016 |
Andrii Kulian <akulian@google.com> |
Fix task selection logic
When task was selected for activity launched with flag FLAG_ACTIVITY_NEW_TASK
first matching task was omitted if there was another match lower in stack.
This lead to task shuffling in same stack.
Bug: 28848683
Change-Id: I94e55693fc7ed926fc151ba988d257bd2417dd45
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| 6afd15641470f174ad27442630563ab4276c6763 |
|
02-Jun-2016 |
Jorim Jaggi <jjaggi@google.com> |
Fix unminimizing dock stack for AppTask.moveToFront
Some apps call AppTask.moveToFront instead of startActivity from
their trampoline activity. We need to handle this case also and
need to do all the post processing after starting an activity
so the docked stack gets unminimized.
Change-Id: I8400995bf1d1a4a4467d01fd55fca7e5800b4645
Fixes: 28722017
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| 2ab4ac38350b51c239fe564bc89727b201036205 |
|
01-Jun-2016 |
Wei Wang <wvw@google.com> |
Merge "Trigger power hints for activity launch" into nyc-mr1-dev
|
| 98f03f98acb4bf8020be21be0f261f3d285b7d2e |
|
18-May-2016 |
Wei Wang <wvw@google.com> |
Trigger power hints for activity launch
BUG: 28220567
Change-Id: Id2a0397efd1dd02ee50d5626edaed9e60ea6de8a
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| 352d584b20af23a6a99958aafcf8127e6dc09894 |
|
19-May-2016 |
Jorim Jaggi <jjaggi@google.com> |
Handle trampoline activites in different tasks
When the app uses a trampoline activity that launches in a different
task than the main task, we fail to show recents when the task is
docked and the user launches the trampoline activity from home. Add
logic to handle this case.
Bug: 28368989
Change-Id: Iea29e6cd1a9919da0e856955691fac4792e30604
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| 13dbfff19eeee73133c976ef6b23298e271a1985 |
|
20-May-2016 |
Wale Ogunwale <ogunwale@google.com> |
Put launch adjacent activity in a new task if the activity does exist
For the launch adjacent case we only want to put the activity in
an existing task if the activity already exists in the history.
Bug: 28828326
Change-Id: I1a6fdd6779cb20f8c0d9b7d94635b21718f4ac1b
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| ae13e18c5561537e062f46ddda8e5dff30d1fe26 |
|
17-May-2016 |
Tony Mak <tonymak@google.com> |
Should check isDeviceSecure in shouldConfirmCredentials
The NPE is because createConfirmDeviceCredentialIntent returns a null
intent when it founds that user does not set a secure lock.
So the fix is we should check is the user set a secure lock screen as well.
The reason the crash only happens in multi-window flow because
we have null checking in
the normal flow (i.e. interceptWithConfirmCredentialsIfNeeded).
But I think we better check it explicitly.
Bug: 28716456
Change-Id: Ib204cd02c0007bd1df36908bb3b5254ec4ffb914
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| 6874114a957051cc9f469363e7583994c2966758 |
|
17-May-2016 |
Wale Ogunwale <ogunwale@google.com> |
Correct activity lifecycle when forcedResize activity is finished
- Regerssion introduced ag/1039265. We still need to resume the
starting activity in a task with an overlay activity is the starting
activity is the overlay activity. Otherwise the activity below it
might not be moved to the paused state.
- Also, we don't want to clear starting window for activities that
aren't behind fullscreen activities as we need to display their
starting window until they are done initializing.
Bug: 28808506
Bug: 28751186
Change-Id: I9a1a5feecea2ed3592a4064fca80e240a3bce387
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| b406dd20eee28eedb8e9f330a0459d630c026515 |
|
17-May-2016 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Fixed bugs with starting windows when displayng forcedResized activity" into nyc-dev
|
| 3b23239d6ec9ded858d75f272ca1a677c5c431f9 |
|
14-May-2016 |
Wale Ogunwale <ogunwale@google.com> |
Fixed bugs with starting windows when displayng forcedResized activity
- Added ActivityOption to mark a starting activity as a taskOverlay
activity. That is the activity will always be the top activity of the
task and doesn't cause the task to be moved to the front when it is added.
- Only set the starting window state of the ActivityRecord to shown if
window manager actually showed the starting window for the activity.
Avoids incorrectly trying to remove starting window for an activity that
didn't show any.
- When starting additional activity in a task, transfer the starting
window from the top most activity with a starting window. It is possible
the top most window does have a starting window like in the case of the
forcedResized activity.
- Only ensure visiblity of an activity we are starting in a task whose top
activity is a task overlay. They need to start in the visible-paused state
and not the resumed state which just causes extra churn in the system.
- Always add additional starting activities in a task with an overlay
activity below the overlay activity.
Bug: 28751186
Change-Id: I3624a4313ae9c406d42c67a3537f67ad685791af
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| 1e630c08296ec6cc311cc4e1c397f7ca50a1a735 |
|
16-May-2016 |
Jorim Jaggi <jjaggi@google.com> |
Fix transition delay tracking when starting activity from recents
- Move logic to determine app switch etc. into ActivityMetricsLogger.
- Make sure the notify the tracker in startActivityFromRecentsInner
Bug: 27295491
Change-Id: Ic68058c88917e3f37183dded2f13cb35055323ee
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| ce4db0a17f7063771f413fd606bb05a3ca54cbca |
|
11-May-2016 |
Fyodor Kupolov <fkupolov@google.com> |
Call isUserUnlockingOrUnlocked with cleared identity
Bug: 28709934
Change-Id: I61fc31e906c8498f19d6d76cd0dc5f2de9738708
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| b7d513cb47ba872bc3e3d4689a67bd05720f8569 |
|
02-May-2016 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Launch home activity in home stack if coming from ResolverActivity" into nyc-dev
|
| 1affbbc5932231d5a1fa4563ef0623b4eaaa9cdd |
|
01-May-2016 |
Wale Ogunwale <ogunwale@google.com> |
Launch home activity in home stack if coming from ResolverActivity
ResolverActivity launches activities it resolves as the initial caller.
In the case of the home intent it can be sys-ui, but only the system
server is currently allow to launch things into the home stack, so the
resolved home activity is placed in non-home stack. This wasn’t a
visible problem in fullscreen mode as the user would notice since
everything is fullscreen, however it is very visible in multi-window mode.
We now allow home activities to be places in the home stack if it is coming
from the ResolverActivity.
Bug: 28487506
Change-Id: I68f81da68a207efab9ce911fa6661bd573f1e949
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| efef374ccf917d079907dd734aee5590809254f9 |
|
01-May-2016 |
Wale Ogunwale <ogunwale@google.com> |
Don't move stack to front when creating a task for activity to be started
This causes foucs to move to the current activity in the stack which isn't
needed. Focus will be moved when the new activity is started in the stack.
Bug: 26381750
Change-Id: Ia76962dc5ba3ce336d2a4e074d14db06eebbe78c
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| 8c2fb9edae4413074186e3d84ccff0eba41b2cae |
|
28-Apr-2016 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Introduce "unlocking" vs "unlocked" nuance." into nyc-dev
|
| ce18c8167766f92856f94a8e88e19de4698960e6 |
|
28-Apr-2016 |
Jeff Sharkey <jsharkey@android.com> |
Introduce "unlocking" vs "unlocked" nuance.
There is a narrow window of time during user unlock where we're
reconciling user storage and dispatching the "unlock" status to
various internal system services. While in this "unlocking" state,
apps need to be told that the user still isn't actually "unlocked"
so they don't try making calls to AccountManager, etc.
The majority of internal services are interested in merging together
both the "unlocking" and "unlocked" state, so update them.
Clarify naming in AccountManagerService to make it clear that a local
list is being used, which mirrors the naming in MountService.
To match UX/PM requested behavior, move PRE_BOOT_COMPLETED dispatch
after the user is unlocked, but block BOOT_COMPLETED dispatch until
after all PRE_BOOT receivers are finished to avoid ANRs.
Bug: 28040947, 28164677
Change-Id: I57af2351633d9159f4483f19657ce0b62118d1ce
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| c875ae74ba4cfe255551d1b011866fcca3bbec88 |
|
27-Apr-2016 |
Jorim Jaggi <jjaggi@google.com> |
Don't move forced resizable info activity to the front
If we start the forced resizable activity with an existing task,
avoid moving that task to the front. This can cause that a previous
task that was moved to the back gets moved to the front again just
because we started that activity. That's not good.
Bug: 28223489
Change-Id: If8acf31b8be98b82665de1015d5621331c37fb64
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| 4ccfc30a80d6b63cc938ce3578b19773ca00a2ea |
|
21-Apr-2016 |
Jorim Jaggi <jjaggi@google.com> |
Animation fixes when task is not resumed
- Make sure to add the activity to mWaitingVisibleActivities
to not destroy the activity before the app transition has
started.
- Defer layouts in startActivityUnchecked so when clearing the
current activities in the current stack, we don't execute the
app transition yet. We need to wait until the new activities
are added as well.
Bug: 28026847
Change-Id: I252cf139e06197ea34329d1466f1f6162f3e7a30
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| b8c5876dc020959e133c0c7975d8ef65e4d47a27 |
|
21-Apr-2016 |
Jorim Jaggi <jjaggi@google.com> |
Keep stack from mReuseTask
When we launch an activity with CLEAR_TOP and NEW_TASK, we clear
all the activities in that task but then we don't reuse the stack,
which can lead to weirdness.
To fix this, we need to keep the target stack in that case.
Bug: 28000613
Change-Id: If85ade73b1036e8a7c0eda418d9f39e8596b8b16
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| 646fe9913e5f5dda3d03d54ed6c6e9463a4161d0 |
|
21-Apr-2016 |
Tony Mak <tonymak@google.com> |
Fix wrong app is launched after solving challenge from tapping notification
PendingIntent.FLAG_ONE_SHOT is needed to prevent the PendingIntent being
reused.
Also, flag and activity option of credential intent in BaseStatusBar
is not same as the one in ActivityStarter. Added a new
function startConfirmDeviceCredentialIntent in AM to centralize it.
Change-Id: I2d9e5923ad5d4d012f10057c409c666c8ca299a3
Fix: 28309964
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| 4ad9856eb815c03723f9fe5f78518077b9c713c7 |
|
20-Apr-2016 |
Jorim Jaggi <jjaggi@google.com> |
Disallow changing stacks if top activity
When we attach an activity to an existing
task, and that task is already on top,
disallow changing stacks altogether even
if launch stack id is set.
Bug: 28026847
Change-Id: Ie70f0585a29dc1b85a5093624fede32110be3c76
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| 853304c0b11921db142a3945ab66fae5f0cc7d8a |
|
18-Apr-2016 |
Tony Mak <tonymak@google.com> |
Show work challenge in if user in docked stack is locked
Register docked stack listener in ActivityManagerService.
If the docked stack is leaving minimized state, check whether the user
of the docked stack is locked. If yes, show credential confirmation.
Also, we now show work challenge in home task.
And we now scan the entire top task to handle the case the work app is
somewhere in the middle of the task. (eg: open personal camera in work app)
Bug: 27565539
Bug: 28094505
Change-Id: Iaf0738f43ae916a535b17949ec0f322bbfb194dc
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| 681fc7b2670542aae0f3b9ef8f6c7a88db984ea9 |
|
15-Apr-2016 |
Jorim Jaggi <jjaggi@google.com> |
Fix wrong transition when dock minimized and docked app launched
When having an app docked and then going home, and then launching
the app from the homescreen, we had a wrong transition because
getTopMost task was already set to the launched app, because
getRunningTasks doesn't exclude the docked stack. Instead of adding
flags for getRunningTasks, which sounds risky, we just pass a "force"
value when we launch recents in this state.
Bug: 27154882
Change-Id: Iee4512fed13115dbbe8b74413ff1fa9b87afa0ef
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| be67c90f4c2255cab3bc036ecdc8d9636ed5e4b5 |
|
12-Apr-2016 |
Jorim Jaggi <jjaggi@google.com> |
Don't log transition time if no process switch
If the process of an activity that is launching has another
non-stopped activity, the data is not that interesting,
so remove the logging in these cases.
Bug: 27295491
Change-Id: I65d4a0e01b1e634a589ce8ecbbab337f0e6497ca
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| d44063cb3fa0ed0507edf7f17e3b46a50fbe55cf |
|
08-Apr-2016 |
Chong Zhang <chz@google.com> |
Fix for activity manager crash due to null task
Use top.task instead of mStartActivity.task, since in case of reusing
top without starting, the latter will not be set.
bug: 28059153
Change-Id: I91ec59203ca9ae650ad1d14fb9a42985a539d597
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| d53f09254ed48365d3a5149d640437d76aed2e5d |
|
07-Apr-2016 |
Jorim Jaggi <jjaggi@google.com> |
Dismiss docked stack when opening non-resizable activity
- Also move the toast to SysemUI as a cleanup.
Bug: 27341740
Bug: 28026841
Change-Id: Ic6196ed75511751c6fadb12fa24574c881100f65
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| 14810c7e3e5c8153183e36a819779cff4a979c89 |
|
28-Mar-2016 |
Jorim Jaggi <jjaggi@google.com> |
Fix null pointer exception
- Make sure to use the correct task to get the stack.
- Don't try to show non-resizable toast when we didn't do
anything.
Bug: 27870378
Change-Id: I69fec6aa792c2f05d905a7c99c05ebdc689ad032
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| a3631b6c2d2af863e7cd14c9b311bbb63299329c |
|
26-Mar-2016 |
Andrii Kulian <akulian@google.com> |
Merge "Improve stack selection logic during adjacent launch" into nyc-dev
|
| c69bd2246f4ec5000591fdc381f84cd90be85b7f |
|
15-Mar-2016 |
Jorim Jaggi <jjaggi@google.com> |
Implement transition for docking task in recents #6
- Use a future to provide the app thumbnail so the app can restart
in parallel when recents draws the bitmap (extremely expensive).
- Don't call startRecents from AM when recents is already running - this
messes up the transition information.
- Make sure to put the task into resizing mode if it needs to be restored
from the disk.
- Some minor fixes for the transition animation spec.
- Add NO_MOVE_ANIMATION to recents flags to prevent wallpaper
flickering.
Bug: 27607141
Change-Id: I7d0c75b88775ab467927b8cf94303ddb60222e7f
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| 2adba07d75419462873dfeef40d4c983d832ed99 |
|
03-Mar-2016 |
Jorim Jaggi <jjaggi@google.com> |
Show a scrim activity if task is not resizable
Add a callback to TaskStackChangeListener which gets fired when the system
might need to inform the user that a specific app might not work in
multi-window.
Use that callback in SysUI to show a translucent activity which scrims the
activity behind to inform that it might not be resizable.
Debounce the information to once per multi-window session, to not make it
annoying.
Introduce launchTaskId to start an activity in an existing task, and protect
that with START_TASKS_FROM_RECENTS permission.
Bug: 27327287
Bug: 27431869
Change-Id: I89e8d653872ab01ba3c1e252b426e5481da0e6ca
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| 4ac2a58e52fdd69d81e3e2cbf3fdde685f5467f9 |
|
25-Mar-2016 |
Andrii Kulian <akulian@google.com> |
Improve stack selection logic during adjacent launch
Adds handling for some cases when activity is launched with flags
FLAG_ACTIVITY_LAUNCH_ADJACENT and FLAG_ACTIVITY_NEW_TASK.
- If target activity is not in focused stack - use current
parent stack.
- If target activity is already on top of focused task - use
focused stack.
- If task is in focused stack but not on top - move to adjacent
stack.
Bug: 27729085
Change-Id: I2041a46056f880dc0ff61b2b7c384c7297a69479
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| e75a9adfbd37f9ec1a9324caceb9d5d7ceed217c |
|
19-Mar-2016 |
Wale Ogunwale <ogunwale@google.com> |
Added support to specify animation duration when resizing stack
Needed for sys-ui to control the duration of various Pip transitions.
Bug: 27674339
Change-Id: I7bad27aaa19755a73c594e88b88b56db033e1a45
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| 8a372a0a280127743ce9a7ce4b6198c7a02d2a4f |
|
16-Mar-2016 |
Jeff Sharkey <jsharkey@android.com> |
Refactoring FBE APIs based on council feedback.
Mostly consists of removing the word "encryption" from most APIs,
since we can't actually make promises about the data being encrypted.
Bug: 27531029
Change-Id: Iace9d7c4e64716abf86ed11847c40f3947e1d625
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| dea4bd980cdede60e3e315a77a879b91e1b1de01 |
|
15-Mar-2016 |
Chong Zhang <chz@google.com> |
Fix black frame when unlocking device via clicking on notification
- Make sure to tell the app to start drawing if it has been stopped, app
could be stopped in visible state.
- When activity is started with NEW_TASK + CLEAR_TASK flags, skip
resuming of the soon-to-be-removed activity, and run enter animation
directly on the new activity. Resuming the old activity causes delay,
and we also run extra enter-exit transition in short succession which
cause glitches.
bug: 27391256
Change-Id: I390ef9fc9855d70a4a9642c06c87cbe548b8b466
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| 8051c5c89060906f5a3a1ca4adb3b53bb423e56b |
|
04-Mar-2016 |
Wale Ogunwale <ogunwale@google.com> |
Don't make home stack visible if starting activity isn't translucent
We allow the home stack to be visible right behind the fullscreen
stack if all the activities fullscreen stack are translucent and
visible. However, if we are starting an acitvity it isn't visible
yet so our check for translucent activities in the fullscreen
stack will return true since there is nothing visible. This will
cause the home stack to the visible and the visiblilty of its app
token set to true in window manager and it been factored into the
transition animation.
In addition to checking if the activity is visible, we now also
check if it is the starting activity when trying to determine if
the stack is translucent.
Bug: 27448511
Change-Id: Icbbd57c0632cc5389c7ac894800a41f75d4bc450
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| fb1c86439c7991237594760a957e7eba1d86df52 |
|
02-Mar-2016 |
Wale Ogunwale <ogunwale@google.com> |
config_supportsMultiWindow for device to specify multi-window support
Devices that have the config set to false will not allow any multi-window
operation.
Also, added ActivityManager.supportsMultiWindow that checks the new config
and also returns false if the device is a low RAM device.
Bug: 27419483
Change-Id: I8dd85c17d290a5a752de3253beb3b34c17d7736d
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| 715a1dcffd06e7d27a6c980a0ac8ca935362f08b |
|
29-Feb-2016 |
Wale Ogunwale <ogunwale@google.com> |
Use realActivity name when comparing if intents are the same
The TaskRecord intent (usually the intent of the root activity) component
names are based on the realActivity (the activity we are actually launching
and not the input alias) and the ActivityRecord intent is based on the input
component name which can be an alias. This leads to issues when we are trying
to compare the intent of a task and an activity to see if they resolve to
the same thing since the component names will be different in the case of
aliasing.
We know base the activity intent component name on the realActivity before
comparing with the task record intent.
Bug: 27403679
Bug: 27112965
Change-Id: I196e03bb018582cbac977fb3ad45354f00f51578
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| 275561a74677f9d6c8f3f2cebc3cfea416ca586d |
|
23-Feb-2016 |
Jorim Jaggi <jjaggi@google.com> |
App transition delay tracking
Add TRON logging for all kinds aspects when we execute an app transition.
Bug: 27295491
Change-Id: Icb0cbdb92d4d5fbfedadd40a017a50eb217058aa
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| 8882ce5c2da1f06f2c153296ec132e7128a07d1a |
|
24-Feb-2016 |
Tony Mak <tonymak@google.com> |
Merge "Should call clearCallingIdentity before accessing getProfileParent" into nyc-dev
|
| 134364556ed574bb40e1f20514bb646173d7d849 |
|
24-Feb-2016 |
Tony Mak <tonymak@google.com> |
Should call clearCallingIdentity before accessing getProfileParent
Bug: 27308833
Change-Id: Ib33fcc0f30dada5f307f45c7c85dce5fb5e4a064
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| ae846f4a15eead9a6e82d5d8668999e724fae36e |
|
22-Feb-2016 |
Wale Ogunwale <ogunwale@google.com> |
Fixed bug with non-focusable stack activity not displaying on start.
Activity manager normally singals window manager that it is okay to
start the app transition process for an activity we are launching
during the resume process. However, the activity will not be resumed
if the activity is been launched in a non-focusable stack
(e.g. pinned stack). So, the app transtion will not start and it will
not be visible until the app transition time's out in window manager.
Activity manager now tells window manager to execute app transitions
if we are launching an activity in non-focusable stack.
Bug: 27224884
Change-Id: I35245fceb2637b927e7885b2c02daa1d55deaabb
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| 31eb784f89c7642f7e61d7dd8c08622e9269e874 |
|
17-Feb-2016 |
Rob Carr <racarr@google.com> |
Merge "Fix issue with activity reuse for aliased components." into nyc-dev
|
| 8f640757c6d9babc6cc331a0af6ba685ad12babd |
|
16-Feb-2016 |
Robert Carr <racarr@google.com> |
Fix issue with activity reuse for aliased components.
In this case of activity aliases, the ActivityRecord intent
member will contain the aliased component name. The TaskRecord
intent member will contain the resolved component name. When
considering an activity for reuse during start, we need to compare
our candidates ActivityRecord intent, not it's TaskRecord intent
as we have not yet resolved the alias.
Bug: 27112965
Change-Id: Ie3a1fb7b306469037372a0328364ca3d4530599e
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| b1b302660cf5b1b1c5b342cc90eca93b8f66890c |
|
09-Feb-2016 |
Kenny Guy <kennyguy@google.com> |
Support FBE for managed profiles.
Allow launcher to see and attempt to launch non-crypto
aware application when profile is locked.
Hide unlock notification until parent user is unlocked.
Have unlock notitication use confirm credentials to unlock
the profile.
Updated notification strings as per suggestions in mocks
to make it clearer between users and profiles.
Bug: 27038260
Change-Id: If2d2c8148670d814544f4edd44193d15da32a289
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| 480dca0d1b08f8895f66f857e9bd341033fab2d9 |
|
06-Feb-2016 |
Wale Ogunwale <ogunwale@google.com> |
Reduce jank during pinned stack animation
- Don’t launch Pip overlay activities during pinned stack animation.
This causes extra CPU load and takes a way resources from the running
animation.
- Finish Pip overlay activities before starting pinned stack resize
animation. Reduces the amount of work the system needs to do to keep
the overlays in-sync with the other activities in the pinned stack.
- Use AM.resizeStack with null bounds to take Pip to fullscreen so that
we can animate the bounds changed.
- Also, fixed Activity.enterPictureInPicture API to animate the transition
if Pip is entered from the app instead of Pip manager.
Bug: 25672053
Change-Id: I82399c10f1b8c675ea3861ba973dc8ecfbfbe50f
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| 47dae5850d44f67a8cd02115f0f7033fd398e223 |
|
02-Feb-2016 |
Filip Gruszczynski <gruszczy@google.com> |
Animate pinned stack resize when launching acivity with new bounds.
Bug: 25672053
Change-Id: Idbcbb77c2442d5e35041f757489f0657daad48c9
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| cd872fb2663ff2e1b018ddbe9187f355c066f5cd |
|
01-Feb-2016 |
Wale Ogunwale <ogunwale@google.com> |
Merge "Improved logic for determining visiblility of activities in the home stack"
|
| 3d7fdc11120869c33d1445c6ed18667008f400df |
|
01-Feb-2016 |
Filip Gruszczynski <gruszczy@google.com> |
Ensure visibility of pinned activity when starting it.
Currently we depend on resuming focused activity within the focused
stack to make it visible. This doesn't work for pinned stack, because
neither the stack nor the activity are focused and as a result the
pinned activity doesn't get resumed and made visible. We need to
explicitly force visibility without focusing the stack.
This fixes two issues:
* pinned activity not showing up when launched from a different full
screen stack activity;
* no entry animation when launching the activity from another full
screen stack.
Bug: 26891834
Bug: 25672053
Change-Id: I83065e10a2d237f1a1f26115e94c6648570e1d7f
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| 673cbd2b6932b39d6804cda2969b7f059c1ce748 |
|
31-Jan-2016 |
Wale Ogunwale <ogunwale@google.com> |
Improved logic for determining visiblility of activities in the home stack
- No other activity in the home stack should be visible behind the home
activity. Home activities is usually a translucent activity with the
wallpaper behind them. However, when they don't have the wallpaper
behind them, we want to show activities in the next application stack
behind them vs. another activity in the home stack like recents.
- We don't want any other activities in the home stack visible if the
recents activity is going to be returning to an application activity
type. We do this to preserve the visible order the user used to get
into the recents activity. The recents activity is normally
translucent and if it doesn't have the wallpaper behind it the next
activity in the home stack shouldn't be visible when the home stack
is brought to the front to display the recents activity from an app.
- Also fixed issue with not setting correct return type for tasks
when they don't have Intent.FLAG_ACTIVITY_TASK_ON_HOME flag set.
Bug: 26571156
Change-Id: I45ef795c6a19ab859e9f6204fb059e875ad798c5
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| 2a25a62739bca2f93aa91fbba698a6de697032b2 |
|
30-Jan-2016 |
Wale Ogunwale <ogunwale@google.com> |
Renamed FLAG_ACTIVITY_LAUNCH_TO_SIDE to FLAG_ACTIVITY_LAUNCH_ADJACENT
Per feedback from API council.
Bug: 26508215
Change-Id: Id17166fe981587c9c16c382ccbdf0846ed2ae5d6
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| b9b16a74e5543b7b707e55a7382bbe82d300e2e5 |
|
27-Jan-2016 |
Wale Ogunwale <ogunwale@google.com> |
Display warning toast when we try to launch unresizeable app in split-screen
Bug: 26774816
Change-Id: Ia85d9d89758041661391018f04feb6f8db4e56d9
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| 513346d8f58e13999133872478a966ea4262701f |
|
27-Jan-2016 |
Wale Ogunwale <ogunwale@google.com> |
Don't allow non-dockable activities/tasks in docked stack.
Prevent activities and tasks that are not resizeable and don't
support crop windows resize mode from going into the docked stack.
Bug: 26774816
Change-Id: I1fd23114685be15908e80e8bc5a0216d8bfd049e
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| b1faf60b896afe235175354ffd90290ff93a54b4 |
|
27-Jan-2016 |
Wale Ogunwale <ogunwale@google.com> |
Use resizeMode integer instead of resizeable boolean.
Changes activity manager and window manager to use resizeMode
as defined by ActivityInfo#resizeMode instead of a boolean.
Bug: 26774816
Change-Id: I8cef46d9fba6bfdd21df7da63ed5d5330ad03d4b
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| cc25a8a24ea85409f440c052fdf36dc304cd7111 |
|
23-Jan-2016 |
Wale Ogunwale <ogunwale@google.com> |
Send notification we attempted to start an already running pinned acitvity
API will be used by Android TV sys-ui to decide what to do next with the
Pinned activity.
Bug: 26452296
Change-Id: I5411515d079468616422ba9e5093164a924cd6a2
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| 58d25998321d9f4b1b76d18a5af9d42cdbaad30d |
|
21-Jan-2016 |
Rubin Xu <rubinxu@google.com> |
Show dialog when launching work apps is not possible.
There are two cases when this could happen. First is when the work
profile is turned off by the user, and the second is when the profile
owner has suspened the package.
Bug: 22776761
Bug: 22541941
Change-Id: Ibc671e93f87dff0168bb7643494b9d6b45a1a7f9
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| 3bcf800c50238ac2df19c9fc0375c303905524b0 |
|
14-Jan-2016 |
Andrei Stingaceanu <stg@google.com> |
Suspend apps - block
* kill app when suspending
* block starting ONLY activities for suspended apps
* do not allow suspending the device admin package
Bug: 22776761
Change-Id: I3ee5fcb2d6828f363ce0f024dbc662ab29275192
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| 08b55823eb3728626e6abc336e9044a50c5cde36 |
|
20-Jan-2016 |
Wale Ogunwale <ogunwale@google.com> |
Merge "Resize pinned stack with bounds in ActivityOptions."
|
| d49352afd40b521cefae3d2ba6f4ef1aff866de0 |
|
20-Jan-2016 |
Filip Gruszczynski <gruszczy@google.com> |
Merge "Revert "Temporary logging to debug ActivityStarter crash.""
|
| 5ded99777adb734a62f7c367b29f589e72955e48 |
|
20-Jan-2016 |
Filip Gruszczynski <gruszczy@google.com> |
Revert "Temporary logging to debug ActivityStarter crash."
Bug: 26541093
This reverts commit 7fca6d50a57cbc1a45beca1d5d1e5cd1e696fbef.
Change-Id: I41fb70e79f2da6523c40f09a74d1980cbeb2149e
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| be9dabdc0f279744953c61b8362c27c858fef135 |
|
19-Jan-2016 |
Filip Gruszczynski <gruszczy@google.com> |
Don't remove task needed for reuse when clearing during activity start.
Bug: 26541093
Change-Id: I4ed39110e9bd72e5f7e11a49acc0a36dc8414df4
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| d3d9ddfa722398d038ad7ecd5e7f55763427c8a4 |
|
19-Jan-2016 |
Filip Gruszczynski <gruszczy@google.com> |
Merge "Temporary logging to debug ActivityStarter crash."
|
| 7fca6d50a57cbc1a45beca1d5d1e5cd1e696fbef |
|
17-Jan-2016 |
Filip Gruszczynski <gruszczy@google.com> |
Temporary logging to debug ActivityStarter crash.
Bug: 26541093
Change-Id: Ia2887c1735ea6a5a964c01b63019288b96ef6172
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| ddb96df9217d870a9d8efda98f0af666eda2b484 |
|
17-Jan-2016 |
Filip Gruszczynski <gruszczy@google.com> |
Fix NPE when checking if recents should be launched in docked mode.
In some cases the activity starting method might return early with
positive return code, even though it skipped doing most of the work
and the target stack is not set. We need to protect ourselves from
an NPE in that case.
Bug: 26541093
Change-Id: I7227ad8efa30c52dd8178ad3c9d8b2263c89a74f
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| 3ee3b9d17b2aec84e791f3efa6b9453cab0d9c9b |
|
16-Jan-2016 |
Suprabh Shukla <suprabh@google.com> |
Merge "Keeping only running users recents in memory"
|
| 09a88f5f3e7d4a3bbfce04ac06594ac590c67d27 |
|
02-Dec-2015 |
Suprabh Shukla <suprabh@google.com> |
Keeping only running users recents in memory
Currently, all the users' recent tasks are loaded into memory and kept
in sync with the persistent storage. This changes the system so
that it loads a users recents into memory lazily (i.e. when
getRecentTasks is called for that user) and unloads them from the
memory as soon as the user is stopped. This also required bucketizing
the taskIds per user, so that the next available taskId can be assigned
without having knowledge of all the tasks that are stored away in
persistent storage but are not available in memory.
Bug-Id: b/24569398
Change-Id: Ia5cb64d9f4ee727225dce34e45ca63e946ac27a8
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| cacfaa216a599522190545b27c54e44ec9533f05 |
|
15-Jan-2016 |
Wale Ogunwale <ogunwale@google.com> |
Resize pinned stack with bounds in ActivityOptions.
If an activity is been launched into the pinned stack and
there is a bounds specified in the ActivityOptions, use it to
resize the pinned stack.
Bug: 26574470
Change-Id: I43c15069b8512ce54cfde6cc16f5caa2a70bd06a
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| 0e381e278a2c2a3a7c86c9951ac5cbcdc3a186f4 |
|
15-Jan-2016 |
Filip Gruszczynski <gruszczy@google.com> |
Fix visible-behind not visible for translucent activity in fullscreen stack.
Bug: 26471802
Change-Id: Ide9945c4478805902ca0df92dc2043359a751600
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| dce2d161701f318ec71f8fe8de03031e1c4b0046 |
|
13-Jan-2016 |
Filip Gruszczynski <gruszczy@google.com> |
Only request stack resize after non full screen bounds were set.
Also make sure that the bounds passed to stacks and tasks are not bogus,
as these would mess up the configuration.
Bug: 26512887
Change-Id: I1a3a9c867a2c258a326b31df2bac614ccbb00579
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| e826f327cfdba8b4957c835d45aaf4f657e87cd5 |
|
12-Jan-2016 |
Filip Gruszczynski <gruszczy@google.com> |
Deliver onNewIntent before onResume when launching recents.
Bug: 25837292
Change-Id: I9da5d2a87c0e33006ef1488dfab5389911955922
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| 303210bbdd2740a9b94ba9a9c10188acd950068f |
|
09-Jan-2016 |
Filip Gruszczynski <gruszczy@google.com> |
Start recents when bringing docked task to the front.
We don't want the docked activity to be on top by itself, so we need to
force the recents to come up to.
Bug: 25838525
Change-Id: Icb8184db5cc67e536561674b887bf481595257cc
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| ea9b10e64419edbd5d3ed13f82007ffed97af418 |
|
04-Dec-2015 |
Clara Bayarri <clarabayarri@google.com> |
Work Challenge: Handle Recents launches
Intercept calls to start activities from the recents
stack and show the Work Challenge if needed. This requires
passing the taskId to ConfirmDeviceCredential so it can
launch the recents task itself when the credentials are
confirmed.
Change-Id: I013b134f3f31a35b551ad683c68cc89b8af44499
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| 01d665686e669b94f0259b83728ba5bb6562e3b8 |
|
29-Dec-2015 |
Wale Ogunwale <ogunwale@google.com> |
Refactored ActivityStarter#startActivityUnchecked to make it easier to follow
Change-Id: I7566e69206753601fbc7b126da8b5db4891a955f
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| 854809c074aabebf5b6520c361d1d3c7c22066d2 |
|
28-Dec-2015 |
Wale Ogunwale <ogunwale@google.com> |
Added hidden API for specifying launch stack in ActivityOptions
Bug: 26273032
Change-Id: Ifb9c70e6783b0426613709693e11742d80ba2fc3
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| 6cae765b67d3a3b37e2cacbc9816665b5bc080b9 |
|
26-Dec-2015 |
Wale Ogunwale <ogunwale@google.com> |
Added support for android.R.attr#alwaysFocusable
Allows an activity to always be focusable regardless of if it is in a
stack whose activities are normally not focusable. For example, activities
in pinned stack aren't focusable. This flag allows them to be focusable.
Also, changed ActivityInfo.#{resizeable, supportsPip} to use flags.
Bug: 26273032
Bug: 26034613
Change-Id: I8c63e6d3256757e2e6931e08b8a65269f5169d35
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| d046a013921c2ac67318c1543a8b7b9c83b40d65 |
|
24-Dec-2015 |
Wale Ogunwale <ogunwale@google.com> |
Consolidate resume activity code around focused stack.
Cleaned up the code to make it obvious that only the top
activity in the focused stack should be in the resumes state.
Bug: 26273032
Change-Id: I8d60270f707fe022007c59d25f5678b33a005acf
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|
| 07a0e4980b43d7f3ef8cf7a62592baca0d78a853 |
|
17-Dec-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Collect activity starting logic into ActivityStarter class.
Change-Id: If1c074d6c278647ec55f2313483945f24aca8b3b
/frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java
|