History log of /frameworks/base/services/java/com/android/server/UpdateLockService.java
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
5ac72a29593ab9a20337a2225df52bdf4754be02 30-Aug-2012 Dianne Hackborn <hackbod@google.com> Improve multi-user broadcasts.

You can now use ALL and CURRENT when sending broadcasts, to specify
where the broadcast goes.

Sticky broadcasts are now correctly separated per user, and registered
receivers are filtered based on the requested target user.

New Context APIs for more kinds of sending broadcasts as users.

Updating a bunch of system code that sends broadcasts to explicitly
specify which user the broadcast goes to.

Made a single version of the code for interpreting the requested
target user ID that all entries to activity manager (start activity,
send broadcast, start service) use.

Change-Id: Ie29f02dd5242ef8c8fa56c54593a315cd2574e1c
/frameworks/base/services/java/com/android/server/UpdateLockService.java
5bb59daf42fb24c1131effd4265c2386304feceb 01-Mar-2012 Christopher Tate <ctate@google.com> Merge: Send UpdateLock broadcasts to manifest receivers

So that e.g. the system update service doesn't need to run all the time.

Bug 5543442

Change-Id: I4cd38240e67851daa5542a2962953e5dbed15b86
/frameworks/base/services/java/com/android/server/UpdateLockService.java
8662cab5c6a01ea5c426512e6f6d2cf3e158aea0 23-Feb-2012 Christopher Tate <ctate@google.com> Merge: Introduce UpdateLocks

An "UpdateLock" works similarly to a wake lock in API: the caller is
providing a hint to the OS that now is not a good time to interrupt
the user/device in order to do intrusive work like applying OTAs.
This is particularly important for headless or kiosk-like products
where ordinarily the update process will be automatically scheduled
and proceed without user or administrator intervention.

UpdateLocks require that the caller hold the new signatureOrSystem
permission android.permission.UPDATE_LOCK. acquire() and release()
will throw security exceptions if this is not the case.

The "is now convenient?" state is expressed to interested parties
by way of a sticky broadcast sent only to registered listeners. The
broadcast is protected; only the system can send it, so listeners
can trust it to be accurate. The broadcast intent also includes a
timestamp (System.currentTimeMillis()) to help inform listeners that
wish to implement scheduling policies based on when the device became
idle.

The API change here is a tiny one: a dump(PrintWriter) method has been
added to the TokenWatcher class to facilitate getting information out
of it for dumpsys purposes. UpdateLock itself is still @hide.

Bug 5543442

Change-Id: I3709c831fc1883d7cb753cd2d3ee8e10a61e7e48
/frameworks/base/services/java/com/android/server/UpdateLockService.java