| a1b79bfd7a15006a93da933695359765e0fee495 |
|
24-May-2016 |
Felipe Leme <felipeal@google.com> |
Allow apps to bypass Power Save restrictions when launched from a Notification's PendingIntent.
This scenario typically happens when the device is on Doze Mode and a
notification action is triggered from a Wear device.
In a nutshell, the workflow is:
- ProcessRecord has a flag telling whether a process has "whitelist
management" privileges.
- When NotificationManager binds a new NotificationListenerService, it
sets the BIND_ALLOW_WHITELIST_MANAGEMENT flag.
- On bind(), ActiveService asserts that only system apps can set that
flag.
- On computeOomAdjLocked(), ActivityManagerService sets the
ProcessRecord flag if necessary.
- Upon creating a notification, NotificationManager calls AM to mark its
PendingIntents as coming from a notification.
- When PendingIntentRecord sends it to the target, it checks if it's
from a notification and if so calls AM to do the temp whitelist.
- On unbind(), ActiveService removes the ProcessRecord flag if necessary.
Fixes: 28818704
Change-Id: I00d46036a2cbb73f7f733fd35bf0b743a02807a1
/frameworks/base/core/java/android/app/ActivityManagerInternal.java
|
| f8451b98150564b340207327d0951f44753338d1 |
|
01-Apr-2016 |
Rubin Xu <rubinxu@google.com> |
Kill foreground apps when turning off work
While work apps will all be killed as we stop the profile user when
turning off work, this can sometimes take a while. So let's kill the
foreground apps as soon as work profile is being turned off to make
the user experience nicer.
Bug: 27631526
Change-Id: Icdd3799385a98ee531b0b4247e8ede78f6f10da8
/frameworks/base/core/java/android/app/ActivityManagerInternal.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/core/java/android/app/ActivityManagerInternal.java
|
| e8222e551f8abd2d82ca4f77ddb275e2e509751e |
|
09-Apr-2016 |
Amith Yamasani <yamasani@google.com> |
Multi-window assist callback
Introducing a new callback in VoiceInteractionSession to
provide assist data for additional activities in the
foreground in a multiwindow setup.
PIP, docked windows and free-form windows (top-most)
will be queried for assist data and passed through the
new API to the Voice Interaction service.
Bug: 27718385
Change-Id: Ib4427c304611b75c2078dcb54f1f7e47ae7d9cfa
/frameworks/base/core/java/android/app/ActivityManagerInternal.java
|
| 192086eb8aff3fb873a7e03ade0b81652aacf25f |
|
11-Mar-2016 |
Jorim Jaggi <jjaggi@google.com> |
Implement transition for docking task in recents #1
- When the docking transition is happening, defer updating
the bounds of the home stack until the transition is done.
This is to preserve the scrim which is drawn in the recents
activity.
- Use the PROLONG_AT_START infrastructure to hide the task
in recents when starting the app transition.
- When recents finally get resized at the end of the transition,
reset it's draw state so we don't move the old surface around,
and the new surface gets drawn at the new position, to avoid
flickering.
- Remove hack around not layouting docked divider if it's not
visible, it's not needed anymore and resulted in a wrong
initial position.
- Fix animation selection for docked stack divider.
- Make sure win.moved() always gets called.
Bug: 27607141
Change-Id: I76c35f09461f044a90e2c88335008284b5839cc0
/frameworks/base/core/java/android/app/ActivityManagerInternal.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/core/java/android/app/ActivityManagerInternal.java
|
| 0af6fa7015cd9da08bf52c1efb13641d30fd6bd7 |
|
18-Jan-2016 |
Amith Yamasani <yamasani@google.com> |
Voice Interaction from within an Activity
This allows an app to show a voice search button
and invoke a voice interaction session for use
within the activity. Once the activity exits, the
session is stopped.
Test application has a new activity that
demonstrates it with the test voice interaction
service.
This initial version is functional enough for
an integration test, with some more tests
and improvements to come later.
Bug: 22791070
Change-Id: Ib1e5bc8cae1fde40570c999b9cf4bb29efe4916d
/frameworks/base/core/java/android/app/ActivityManagerInternal.java
|
| 515d40600e1f11c7cea3a2bfbbb49e7d86ff801f |
|
28-Sep-2015 |
Amith Yamasani <yamasani@google.com> |
Delay cleaning user tasks until user is removed
Fixes #24301208 No recent apps shows when switching
between users.
Instead of cleaning up when stopping a user, we
should remove tasks when removing a user, since
recents tasks should be persisted across reboots.
Reboots are similar to stopping and starting users.
Change-Id: I9a250792077cca5f18ae1a10bc36f7b97e8ea867
/frameworks/base/core/java/android/app/ActivityManagerInternal.java
|
| b501330a1b6ef14ff512a5727f7a01bc423d6fbb |
|
18-Apr-2015 |
Fyodor Kupolov <fkupolov@google.com> |
Disable multi-user background recording
On user switch, kill existing processes of the background user with
android.permission.RECORD_AUDIO permission. Home activity should not be
killed to avoid an expensive restart of the home launcher, when the
user switches back.
Introduced DISALLOW_RECORD_AUDIO user restriction, which is enabled for the
background user, and removed for the foreground user.
Introduced a concept of system controlled user restriction, which can only
be set by the system, rather than device administrator.
Bug: 20346194
Change-Id: Ic942fd565e80d14424230dae612965a8e229c4ef
/frameworks/base/core/java/android/app/ActivityManagerInternal.java
|
| 061ea99546fbba1da86094518992cf6b7a125278 |
|
18-Apr-2015 |
Jeff Brown <jeffbrown@google.com> |
Make activity manager sleep top activity when dreaming.
Added the concept of a sleep token to represent a demand to sleep.
We grab this token whenever a dream window is visible.
This change also deletes a special condition in shouldSleepLocked()
which would tend to keep activities running when the lock screen
was shown unless they had previously been sleeping. I believe this
condition is no longer necessary and the policy is much simpler
without it. Let's see if anything breaks.
NOTE: This can currently only be used within the system server process
but it might make sense to move it to IActivityManager (guarded by
DEVICE_POWER permission) so that keyguard can use it. If we added
a callback on release to inform the client that the underlying activity
has finished drawing then we could untangle a bunch of keyguard
specific logic.
Bug: 18866521
Change-Id: I84b2118f5b990a71a1647d1cee536ad3d99f3a24
/frameworks/base/core/java/android/app/ActivityManagerInternal.java
|
| fbe96706bb9754f9ea3f6345f32e058a45ad10b4 |
|
20-Nov-2014 |
Jeff Brown <jeffbrown@google.com> |
Support keeping activities resumed while dozing.
If the lock screen is not shown, then let activities keep running
while dozing. This is important to support ambient mode on watches
since it allows the home app to keep running.
To make this possible, we need to inform the activity manager about
the exact wakefulness state, not just the overall boolean
interactive state.
Bug: 18284212
Change-Id: Ia35c99127ce51ffc178f3a2f51fca67d24061c71
/frameworks/base/core/java/android/app/ActivityManagerInternal.java
|
| 810c052d9b117217152c2a609ccec056a2a61d1e |
|
25-Jul-2014 |
Primiano Tucci <primiano@google.com> |
Cherry pick Introduce startIsolatedProcess private API in ActivityManager DO NOT MERGE
The new API spawns a isolated process, using a custom uid, entrypoint and
abi. Such API is used by the WebViewFactory to spawn its unpriviledged
but trusted process (hence the fixed uid) which rewrites the rerlo file
on boot / when an update occurs.
Since both the ActivityManager service and the WebViewUpdate service
live in the SystemServer their calls be dispatched locally and no
binder interface needs to be exposed for the new startIsolatedProcess API.
Original BUG:16403706
Original Change-Id: I327b59735c12698595e0dbcc4da5d759c9103b0a
Bug: 16723226
Change-Id: Iecb49888e11eec9d302d9712953fd498db5821af
/frameworks/base/core/java/android/app/ActivityManagerInternal.java
|
| 13014b5fe5967b3c7e232ffaf81581ed178e6df6 |
|
08-Apr-2014 |
Jeff Brown <jeffbrown@google.com> |
Move certain internal activity manager methods to new class.
This is a little bit of refactoring in preparation for changing how
the power manager notifies system components about changes in power
state.
Deleted the startRunning method since it is no longer useful.
Bug: 13133142
Change-Id: I7f845c61ecc7ee890154ed0cbd90795de609b7ea
/frameworks/base/core/java/android/app/ActivityManagerInternal.java
|