We don't want these messages to get blocked by UI traversals.
Added a convenience for creating Handlers that always send
asynchronous messages.
Change-Id: Id568e87fcb8b169e8c52c5fe1dc76a4a5771570b
For now only the device owner "user" gets cloud backups. Also, only the
device owner account has access to local backup/restore.
Bug 6956438
Change-Id: I87d7ba5969e606c23f4214469f9bf2fd47a6c61b
Moved a bunch of methods from PackageManager to UserManager.
Fix launching of activities from recents to correct user.
Guest creation APIs
Change-Id: I0733405e6eb2829675665e225c759d6baa2b708f
* commit 'cb80cb700d15319c20686998e822aed32a56adf5':
StorageManager: fix issue that GREF has increased to 2011 in system server with intel stress test.
* commit '37548994e69292932e9e2fafb7cba6c53e3a2bcd':
StorageManager: fix issue that GREF has increased to 2011 in system server with intel stress test.
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
Change the default value of android:exported to true
for applications which target a newer API version.
This will help stop inadvertent content provider
exposure to untrusted apps.
Bug: 3306452
Change-Id: I8cb34e823aef9551319951ce92217345c54cee63
Issue description:
When run ICS stress test, always meet GREF issue. one of contributor is MountService$MountServiceBinderListener.
log info
19:21:11.609 222 24316 W dalvikvm: 24 of com.android.server.am.ActivityManagerService$AppDeathRecipient (24 unique instances)
19:21:11.609 222 24316 W dalvikvm: 479 of com.android.server.MountService$MountServiceBinderListener (479 unique instances)
19:21:11.619 222 24316 W dalvikvm: 7 of com.android.server.accessibility.AccessibilityManagerService$6 (7 unique instances)
Note: PID 222 is system server.
Issue alaysis:
Everyone can call getSystemService(Context.STORAGE_SERVICE) to get service.
When other service get StorageManager, StorageManager will new MountServiceBinderLister and
register a listener in MountService, which won't be unregistered. It's easy to generate a lot of
instance of unused MountService$MountServiceBinderListener in system server.
Issue fix:
So change the policy to be:
1. Doesn't new MountServiceBinderLister in construction.
2. when other service needs to register listener in StorageManager,
StorageManager will register listener with MountService.
3. When other service needs to unregister listener in StorageManager,
if there is no more other listeners in StorageManager, StorageManager
will unregister listener in MountService.
Change-Id: Iaaf889f44a1a5f62b9f65b3ab1b486c9b7dcaf7f
Author: Chuanxiao Dong <chuanxiao.dong@intel.com>
Signed-off-by: Bo Huang <bo.b.huang@intel.com>
Signed-off-by: Jack Ren <jack.ren@intel.com>
Signed-off-by: Bruce Beare <bruce.j.beare@intel.com>
The wrong constant was used to count the number of user activity types.
The number of types changed recently, so before then nothing bad
happened. Now we get an AIOOB.
This is the change to NUM_USER_ACTIVITY_TYPES:
Change-Id: I05045180129b30fa09fe5f5e1e3b0ac25fee23b4
https://googleplex-android-review.googlesource.com/#/c/211982/
We only support a few basic kinds of wake locks. Rather than
pretend that we could support other weird combinations of features,
just get rid of the feature bits.
Deprecated other wake lock types. We really want to encourage
developers to use FLAG_KEEP_SCREEN_ON instead of managing
their own wake locks, even though its behavior is not
exactly equivalent.
Change-Id: Idfeb0bc6efff0ef2736e47f72a06e69e5a16996e
Looks like BatteryStats was not updated when we reduced the number
of user activity types from 7 to 3.
Change-Id: I7465f86c78baa561a6555c33f681553b870827f2
Changes to make Bluetooth Service part of the system_service.
These changes may be temporary.
Changes to update to the new disable API.
Change-Id: If89dba17e6e6c6daa53c37684221763a2da076e9
Conflicts:
services/java/com/android/server/pm/PackageManagerService.java
This allows selected kernel workers to use 1, while audio preempts them
with 2 and 3.
Bug: 6461925
Change-Id: Ie132235f3027964749509f493fea44b48426c491
Mostly just moved the code around and improved the docs.
Fixed a minor inefficiency in WakeLock.setWorkSource() where
we would tell the power manager that the work source was changed
even when the old work source and new work source were both null.
Fixed a bug in WakeLock.setWorkSource() where we would not
notify the power manager that the work source was changed if
there was no work source previously specified.
Added synchronized to WakeLock.setReferenceCounted.
Added a checked in WakeLock.acquireLocked() and WakeLock.release()
to check whether the wake lock is actually not held / held
before performing the corresponding operation. This change avoids
making redundant calls into the power manager service in the
case where the wake lock is not reference counted and acquire()
or release() have been called multiple times.
Made the PowerManager and WakeLock classes final. They are not
directly instantiable by applications so this change does not
break the API.
Removed a little dead code (one private constructor and an
unused constant).
Change-Id: I4e10cf893506115938a35756136c101256dccf30
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