Use AtomicFile for usermanager files.
Added a MANAGE_USERS permission that apps (signature permission) can use
to create/query/modify/remove users.
Change-Id: I5cf232232d0539e7508df8ec9b216e29c2351cd9
User specific entries in mProvidersByNamePerUser and mProvidersByClassPerUser
isn't cleared when entire user specific providers are removed. Fix is to remove
the user specific hashmap in such cases.
Change-Id: I6edf211ced873e59f3b89ffceb9eceec13ea8f3f
Emulated external storage always has multi-user support using paths
like "/data/media/<user_id>". Creates and destroys these paths along
with user data. Uses new ensure_dir() to create directories while
always ensuring permissions.
Add external storage mount mode to zygote, supporting both single-
and multi-user devices. For example, devices with physical SD cards
are treated as single-user. Begin migrating to mount mode instead
of relying on sdcard_r GID to enforce READ_EXTERNAL_STORAGE.
Bug: 6925012
Change-Id: I9b872ded992cd078e2c013567d59f9f0032ec02b
Get rid of duplication between find/retrieve service funcs; when
a service in a persistent process crashes, restart it immediately
since the persistent process is going to be immediately restarted
anyway; when a new process is attaching, immediately restart any
services associated with it that are waiting to restart, since
it is weird to not let them run if the process comes back for some
other reason.
Change-Id: Id087fe04ebf2b6a4bd00732796c8326364765ea7
A long time ago, we had a concept of an "empty" process -- this was
a process that didn't have any interesting components in it, which
would be placed below everything else in the LRU list.
Empty processes didn't work out well, because you could get into
bad situations where you have filled your LRU list with things that
have hidden activities, pushing empty processes to the bottom and
being immediately killed as soon as they go into the list. So this
was removed.
This change brings the concept back, but in a slightly different
form, to address a more specific problem: for people who are switching
between N different applications, we would like to try to keep those
activities available in RAM in a consistent manner. Currently the
previous activities would be killed often quickly and suprisingly,
even on devices with lots of RAM. This is for two reasons:
(1) As you sit in one application, other things going on in the
background will go to the top of the LRU list, pushing down the
previous apps you have visited, even though you aren't aware at all
of these other things executing.
(2) There is a hard limit on the number of background processes
(currently 16) after which they are killed regardless of the amount
of available RAM. This is desireable because if there is lots of
RAM we can end up with tons and tons of processes sitting around,
not really serving any purpose, but using up resources.
To improve the situation, we have again a concept of "empty" processes
but now it means one with no activities. Processes that aren't empty
but in the background list are called hidden. We maintain these as
two parallel lists, each getting half of the process limit: so with
a 16 process limit, you can have at most 8 empty and 8 hidden processes.
This allows us to consistently keep up to 8 recent applications around
for fast app switching; we will also keep around 8 other processes to
make it more efficient for background work to execute again if it needs
to.
Change-Id: Iee06e45efc20787da6a1e50020e5421c28204bd7
Moved a bunch of methods from PackageManager to UserManager.
Fix launching of activities from recents to correct user.
Guest creation APIs
Change-Id: I0733405e6eb2829675665e225c759d6baa2b708f
Added a new method to Context: startActivityAsUser() requiring the
INTERACT_ACROSS_USERS_FULL permission.
Show the correct Recents list, based on current user.
Added a getRecentTasksForUser() in ActivityManager. Hidden and requires
the INTERACT_ACROSS_USERS_FULL permission.
Change-Id: If5b56465efdd3ead36601a3b51ed4af157bbf35c
- You can now use android:singleUser with receivers and providers.
- New API to send ordered broadcasts as a user.
- New Process.myUserHandle() API.
For now I am trying out "user handle" as the name for the numbers
representing users.
Change-Id: I754c713ab172494bb4251bc7a37a17324a2e235e
- Expose the existing Context.sendBroadcast() as
Context.sendBroadcastAsUser().
- Add new android:singleUser attribute for services.
- Add new INTERACT_ACROSS_USERS_FULL permission for full
system-level access to cross-user interface (allows
sendBroadcastAsUser() to send to any receiver).
- Add new INTERACT_ACROSS_USERS_FULL permission for
more restricted cross-user interaction: this is required
for android:singleUser, and allows you to use
sendBroadcastAsUser() but only to send to your own
receivers.
Change-Id: I0de88f6718e9505f4de72e3f45d29c0f503b76e9
Fix a couple of bugs that turned up.
Remove touch/focus from display. Add iterators for access.
Respond to comments. Remove TODOs, and some deviceId parameters.
Change-Id: Idcdb4f1979aa7b14634d450fd0333d6eff26994d
Use raw arrays instead of ArrayList for data structures.
Temporarily includes a copy of the old intent resolver for
validating the new implementation.
Change-Id: I988925669b6686ac73b779be6cd6fe3a9fd86660
- There was a long-standing bug when using FLAG_ACTIVITY_REORDER_TO_FRONT
where we could find and use an activity that is currently finishing.
- There was a recently introduced bug where activities being destroyed
would not be removed from the history stack at the time they are done
being destroyed, allowing the above bug to be exposed.
- Removing a task would not kill any processes associated with the app
that had a different name from the app itself.
Change-Id: I4401ab6d348a69e1ac4fb8f719d2c69d5a78e567
FLAG_ACTIVITY_CLOSE_SYSTEM_DIALOGS was a mistake.
Instead, and the infrastructure for the status bar to take care
of closing and hiding things itself when you press these buttons,
just like it does for the main Intent of the notification.
Bug: 6717667
Change-Id: I1b22186e0cedc05f46a1a3ec78053a72afaf61b1
Make sure that all cases where we remove an activity from the history
stack, we call resumeTopActivityLocked() to cause the home activity
to be launched if the stack is now empty.
Also fixed a problem where some timeouts would not be removed when destroying
an activity, and a race condition in boot that would cause the
PhoneWindowManager to initially start out with the home key not working.
Bug: 6381224
Change-Id: If046bb01aed624b0d9ee3bbaaba68ed6b98fd1d0
...lock screen does not response to onNewIntent()
We now keep activities stopped even while the lock screen is
displayed. (We used to keep them stopped while the screen was
off, and then resume the top activity when the screen was turned
on even though they are covered by the lock screen.)
When a new intent is being delivered to an application, if it
is not resumed it is held in a pending list until the next
time the activity is resumed. Unfortunately that means for
the case where the activity is being held stopped due to the
screen off or lock screen, it will not receive any new intents,
even though it is at the top of the stack.
Fix this by adding an additional condition that allows the new
intent to be delivered immediately if the activity manager is
sleeping and the target activity is at the top of the stack.
Also some debug output improvements, since pending new intents
were not being included in the debug output, making it impossible
to see we were in that situation.
Change-Id: I5df82ac21657f1c82e05fd8bf21474e883f44e6f
Call noteWifiScanStartedFromSource() when a scan is started.
Call noteWifiScanStoppedFromSource() when a scan is finished.
The current implementation tracks to UID that requested the scan, and
correctly tracks the duration of the scan. It ignores scan requests
that occur when a scan is already in progress. It does not distinguish
between active and passive scans.
Repurpose all the noteScanWifiLockAcquired/Released() plumbing
for WIFI scan tracking. The WIFI scan locks were never reported
to the user. Use noteFullWifiLock() when WIFI scan locks are used -
this makes sense because the power draw for a WIFI scan lock
should be about the same as for a full WIFI lock.
Bug: 6642581
Change-Id: Ida6e87992853698545b89f875c973a239218317d
Weren't cleaning out any ActivityOptions that are still attached
to a finishing activity.
Bug: 6636731
Change-Id: If0520bbcbf1d4ce19d46ff769918893cefda9c87
