Activity.setImmersive(boolean) / android:immersive="bool" are now public.
In addition, if the foreground activity is immersive then an update lock
will be held on its behalf. This lets applications such as movie players
suppress the display of intrusive notifications, OTA-availability dialogs,
and the like while they are displaying content that ought not to be
rudely interrupted.
The update lock aspect of this mode is *advisory*, not binding -- the
update mechanism is not actually constrained; it simply uses this information
in deciding whether/when to prompt the user. It's more a guideline than
a rule.
Bug 6154438
Change-Id: Ibd3491fc437077f3fa0d9708ed91955121e8c877
Doing this to accomodate some really long warning text in a
checkbox widget. Needs 5 lines for English. Probably a lot
more for German, etc., so increasing it to 10 lines.
Please don't abuse that. 4 lines is still a reasonable max.
Change-Id: Ife5858f2165cb2bc046ce606f29d31010d26ecc2
For devices that don't care about the previously default bluetooth profiles,
add a config var to disable them.
Change-Id: I21a894130d280016cfd5db1b8bbda70cbef348c3
The key chord screenshot mechanism introduces significant latency into
processing of volume-key input; enough to be quite noticeable and
annoying on some kinds of device. This patch introduces a new config
resource entry ("config_enableScreenshotChord"), true by default, so
that products on which this functionality is inapplicable can avoid
its runtime overhead.
Bug 6039047
Change-Id: I3da16080d3a6842f50da8a8b677153dca943382a
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
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
