Using the system service identity to check the CHANGE_CONFIGURATION
permission isn't likely to catch a security violation. Changing
back to the original caller and then checking permissions is
preferred.
Cherry picked from lmp. Fixes bug 15989465.
Change-Id: Iff08d04422bcc052a487194154f1fd0d727d38f4
Fix for the synchronization issue leading to access of an array
Index out of bounds. Issue occurs due to race condition between
removing the activities of a crashed process from history stack
and resuming a separate activity.
Change-Id: I14bb5834e778c15b674248e46fe93b0ce9f37967
This has the full filter functionality, but is currently only
able to block Activity intents. Logging intents, or blocking
service/broadcast intents is not yet implemented.
Change-Id: Ied3d8dedf982e17bcbdff3e328eeb87477954df7
Keeping all activity=>task changes in master and removing them
from jb-mr2.
Revert "Update histories simultaneously."
Revert "Add null check to setAppGroupId."
Revert "Fix crashing bug in validator."
Revert "Switch topRunning* and moveTaskTo*"
Revert "Begin switch over to task based history."
Revert "Reset and reuse Iterators and don't new() one."
Revert "Remove AppWindowToken lists."
Revert "Fix build."
Revert "Remove unused App methods."
Revert "Stop using AppToken movement and start using Task."
Revert "Replace access to mAppTokens with AppTokenIterator"
Revert "Refactor setAppOpVisibility implementation."
Revert "Add AppWindowTokens to TaskList."
Revert "Make ActivityStack.mHistory private."
Revert "Migrate AppWindowToken lists into DisplayContent."
Change-Id: I5722c9a4956dccb52864207e2967690bc58e4ebb
In moveTaskToBackLocked calls that used mHistory were being made
between the times that mTaskHistory and mHistory were modified. This
caused an inconsistent state that led to Windows arranged out of
order. Updating both history stacks at the same time fixes this.
Fixes bug 8244261.
Change-Id: I9669762ad39b06ab6d401122702b74969d4dc658
- More of the Activity to Task changeover.
- Fix bug in validateAppTokens().
- Improved validation of changeover.
- Eliminated iterator classes.
Change-Id: I934a208eabfc9a2668e5a6162452e1406f2c8d3a
In preparation for converting ActivityManager control to a task-based
interface the AppWindowTokens are being stored per-display.
Change-Id: Ie5e355219554523f5e56eaef138d382975cf1682
Improve handling of vibration op, so that apps are
better blamed (there is now a hidden vibrator API that
supplies the app to blame, and the system now uses this
when vibrating on behalf of an app).
Add operation for retrieving neighboring cell information.
Add a new op for calling a phone number. This required
plumbing information about the launching package name through
the activity manager, which required changing the internal
startActivity class, which required hitting a ton of code that
uses those internal APIs.
Change-Id: I3f8015634fdb296558f07fe654fb8d53e5c94d07
A previous change to avoid losing activities if their process
happens to be gone at the point of launch (by counting that
activity as having its state saved) has resulted in a problem
where an activity that crashes during launch will be repeatedly
relaunched.
This is fixed here by explicitly keeping track of our attempts
to launch the activity since it was last able to save its state,
and not keeping it around if it looks like the launch is
repeatedly failing.
Change-Id: Icefd952443b7eb1222f233db95e0157fc3dd72d1
This keeps Recents from taking two identical screenshots, one for
the Recents thumbnail and one for the pause activity thumbnail.
Fixes bug 7351766.
Change-Id: Ia4d12802151666ec36e4d9b395cf10e1e02dc37f
Many media files and source code files were marked as executable in Git.
Remove those.
Also a shell script and python script were not marked as executable.
Change-Id: Ieb51bafb46c895a21d2e83696f5a901ba752b2c5
When we are clearing activities off the top of a task, propagate
any activity options down from the top-most one to whatever top
activity we are keeping. This ensures that if we set the activity
options on the top activity of the task previously to give it the
correct animation, we still keep that animation for the activity
that really ends up being the top.
Change-Id: I6919b644a530ac283fe4d320496edc2bf72aa04e
The new attribute allows an Activity such as the alarm to appear
on all users screens.
Bug: 7213805 fixed.
Change-Id: If7866b13d88c04af07debc69e0e875d0adc6050a
Add a new call to the activity manager for the input dispatcher
to report about any pid having an ANR. This has a new feature
where it can also tell the activity manager that it is above the
system alert layer, so the activity manager can pop its ANR dialog
on top of everything if it needs to. (Normally we don't want
these dialogs appearing on top of the lock screen.)
Also fixed some debugging stuff here and there that was useful
as I was working on this -- windows now very clearly include
their uid, various system dialogs now have titles so you know
what they are in the window manager, etc.
Change-Id: Ib8f5d29a5572542cc506e6d338599ab64088ce4e
Mostly (turned off) debug output. Main fix is to resume the next
activity if we are pausing while sleeping and the top activity is
not the now pausing activity. Also helped things by fixing a problem
where removing a task would leave around dead destroy timeout
messages.
Change-Id: I9d550c216b4d7e2afe3d93553bb680cec41e2ed1
...Forground Sometimes Doesn't Take
The main change here is a one-liner in ActiveServices to check the
uid when deciding whether to remove an item from mPendingServices.
This could cause the problem being seen -- if the same service for
two users is starting at the same time, the second one would blow
away the pending start of the first one. Unfortunately I have had
trouble reproducing the bug, so I don't know if this is actually
fixing it. It's a bug, anyway.
The reason so much has changed here is because I spread around
logging and printing of the user ID associated with operations and
objects to make it easier to debug these kind of multi-user things.
Also includes some tweaks to the oom manager to allow more background
processes (I have seen many times in logs where we thrash through
processes because the LRU list is too short), plus to compensate an
additional time-based metric for when to get rid of background processes,
plus some new logic to try to help things like Chrome keep around
their service processes.
Change-Id: Icda77fb2a1dd349969e3ff2c8fff0f19b40b31d3
Issue #7209355: Intent on the secondary user results in an intent picker
in the Primary user.
Issue #7214271: Crash in system UI
Also fix a bug where I recently broke the removeTask() operation in the
activity manager where it would remove the wrong task.
Change-Id: I448c73a0e83a78d9d8d96b4629658c169888d275
Keep track of user creation and last logged-in time.
adb shell dumpsys users
User switcher shouldn't show users about to be removed.
No need to check for singleton for activities.
Bug: 7194894
Change-Id: Ic9a59ea5bd544920479e191d1a1e8a77f8b6ddcf
The way it should have been, and with the new recents enter animation
the way it must be.
Added a new method to retrieve this thumbnail, since it would be less
efficient to use the existing API (which always returns the "base"
thumbnail). Probably at some point that existing API should be tweaked
to always return the top thumbnail instead, but that is for a later time.
Also removed code that would clear the thumbnail associated with an
activity when it is resumed. I don't think there should ever be a
reason to clear a thumbnail -- it's much better to have *something*
for the task, even if it is a little out of date.
Change-Id: I83e6ca6403eb2df5e4de3009dfe8c210e8cf8d5b
Add a new call to the activity manager to tell it when the activity
is resumed, so it can mark its state as dirty then instead of when
it first tries to create it.
Also tweak things to update the LRU list for the upcoming activity
at the point we start pausing the current activity, to avoid an
inefficiency where we may decide to kill the process of the upcoming
activity if it is at the end of the LRU list.
Change-Id: Ia6dc8c34dc6d4b085a1efbe3a5d5f47721d55078
- New public APIs to find out when a user goes to the foreground,
background, and is first initializing.
- New activity manager callback to be involved in the user switch
process, allowing other services to let it know when it is safe
to stop freezing the screen.
- Wallpaper service now implements this to handle its user switch,
telling the activity manager when it is done. (Currently this is
only handling the old wallpaper going away, we need a little more
work to correctly wait for the new wallpaper to get added.)
- Lock screen now implements the callback to do its user switch. It
also now locks itself when this happens, instead of relying on
some other entity making sure it is locked.
- Pre-boot broadcasts now go to all users.
- WallpaperManager now has an API to find out if a named wallpaper is
in use by any users.
Change-Id: I27877aef1d82126c0a1428c3d1861619ee5f8653
Bug #7132226: Can't start instrumentation due to ActivityManagerService crash
Bug #6912004: tap on gmail notification sends me to home screen
Change-Id: I824128b01f368de95dee288f8e49039b84479a7e
