summaryrefslogtreecommitdiff
path: root/tests/DynamicCodeLoggerIntegrationTests/src/cpp/test_executable.cpp
diff options
context:
space:
mode:
authorChristopher Tate <ctate@google.com>2012-02-23 14:59:36 -0800
committerChristopher Tate <ctate@google.com>2012-02-28 15:01:30 -0800
commit66e817655a239f8738ce73e06bb1496b2e818f74 (patch)
treee0e670ac912d83acc824a42445784465c09860cf /tests/DynamicCodeLoggerIntegrationTests/src/cpp/test_executable.cpp
parent38b9ca514bdcfbf277f216a29a9f219521836625 (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