| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The javadoc of TokenWatcher promised to implement repeated calls to
acquire() with the same token as a no-op, but this wasn't the case.
When acquire() is called repeatedly with the same token, its associated
DeathRecipient object is replaced by a new one. The old DeathRecipient
can therefore be destroyed. This is problematic because the finalizer of
this DeathRecipient implementation calls release() on the same token,
resulting in the token being released unexpectedly.
In this CL we properly implement the documented no-op behavior.
Bug: 68368071
Test: (First, cherry-pick to internal master)
Test: cts-tradefed run cts-dev -m OsTest -t android.os.cts.TokenWatcherTest
Test: CTS verifier > Managed provisioning > Device owner tests
> LockTask UI
Change-Id: Idfad7c88075a510ea1f8527b5a8620121a5dd7bb
|
| |
|
|
|
|
|
|
|
| |
Many media files and source code files were marked as executable in Git.
Remove those.
Also a shell script and python script were not marked as executable.
Change-Id: Ieb51bafb46c895a21d2e83696f5a901ba752b2c5
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| | |
|
| | |
|
| |
|
