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
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
For kiosk-type devices that do not present any navigation UI. This allows
for clean selection of the implementation based on resource overlays,
without the need for the tablet or phone status bar implementations to
accomodate the desired behaviors.
Bug 5824373
Change-Id: Ia5aca7df70a11e632eaf9be6e67900ded8ea2f7d
This is a grotesque hack to avoid showing status bar controls. The real
solution will be coming via master but not extremely soon; stay tuned but
this gives the right presentation for now without affecting normal products.
Bug 5824373
Change-Id: Ib5348024853ad2e7715b824aba522d80b6a99048
Since CDMA doesn't use APN settings there was no place to say what a cdma
device's DUN connection would support, so by default normal device
originating traffic would be blocked on a tethering single-connection device.
With this change you can (via overlay) say that it supports everything
so mms and on-device browsing/email will still work even when on a dun connection.
The reason to allow both: some carriers will charge per byte for dun access
and so they don't want lots of non-tethering traffic used (costs the user alot)
but other carriers just use a dun connection to limit access to tethering, but
once there give unlimited data, so it makes sense to support everything there.
bug:5972599
Change-Id: I78fd7f3ac63c51a0560b659ed5ec219b10a93f8d
This patch is adding a capability so that OEM can override USB mode
in case the device is boot up with OEM specific mode. (i.e. modem
debug, factory test etc.)
Bug:5964042
Change-Id: Ic8e23d302563ce71eedb74ce94cca8c65838a4f7
* commit '0b2701b7344fb7b7b6f9a1c1c99c8ede81b49d2d':
docs: change that stated as a few doc fixes and turned into fully documenting the device default themes and fixing many more, including adding API level information for older themes to avoid confusion. Oh and fix an unclosed <em> tag causing a format bug.
fully documenting the device default themes and fixing many more,
including adding API level information for older themes to avoid confusion.
Oh and fix an unclosed <em> tag causing a format bug.
Change-Id: Ia4b33559bd5ad2cbae8b53966999cf7f5038b125
incorrectly specified.
This affected search bars and alert dialogs spawned from activities
using Theme.DeviceDefault.Light as a base.
Change-Id: I219d38d486498db5b4b283560256afd7d6051535
