* commit '4143781cdea0741ce6e87967c4ab903288c3e4c3':
docs: add docs for market OBB includes splitting the Licensing dev guide into multiple pages; Turned original licensing doc into a redirect to the new files that are under guide/market/licensing/; Fix all links pointing to app licensing
includes splitting the Licensing dev guide into multiple pages;
Turned original licensing doc into a redirect to the new
files that are under guide/market/licensing/;
Fix all links pointing to app licensing
Change-Id: Ic49493f0e560db225dd7a382ffabc904a2fa1228
Watches for package changes so it can dynamically adjust
to reflect the actual list of available activities.
Change-Id: I3a2fef3dac4d13d1b2a7ed6fc117a7b814679669
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
...if the process is killed and restarted
Try to ensure that in all cases we deliver an activity result if one
was requested.
Change-Id: Id43e830d2ee782f98ed1e3b68e5e16f3258d4ad8
1. The NumberPicker was showing the IME if the input field
gets focus and hiding it when the the arrows are pressed.
The leads to a nasty behavior when the input is the first
focusable and the uses presser an arrow button. In such
a case the IME shows and hides on every arrow press pushing
the window content up and down - this looks pretty ugly.
Now the IME is show on double tap of the input field.
2. The NumberPicker input now by default has an IME action
done, hence after editing it the IME goes away.
3. The NumberPicker input now clears focus when it gets
IME action done, so the last picker in a sequence
does not show selection which is focus driven.
4. NumberPicker was incorrectly detecting double tap to
begin edit and it was possble to start edit on singe tap
if the user has double tapped before to start an edit.
Now double tap detection is using the double tap timeout
correctly.
bug:6071977
Change-Id: I0ff5a491064e51663b3abec675d839d0a65b986a
