diff options
| author | Christopher Tate <ctate@google.com> | 2012-02-23 14:59:36 -0800 |
|---|---|---|
| committer | Christopher Tate <ctate@google.com> | 2012-02-28 15:01:30 -0800 |
| commit | 66e817655a239f8738ce73e06bb1496b2e818f74 (patch) | |
| tree | e0e670ac912d83acc824a42445784465c09860cf /tests/DynamicCodeLoggerIntegrationTests/src/cpp/test_executable.cpp | |
| parent | 38b9ca514bdcfbf277f216a29a9f219521836625 (diff) | |
Introduce UpdateLocks - "now is not a good time for non-interactive OTA"
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: Ic1548dd43935f45d4efc67f970abdc290a45f715
Diffstat (limited to 'tests/DynamicCodeLoggerIntegrationTests/src/cpp/test_executable.cpp')
0 files changed, 0 insertions, 0 deletions
