* commit 'd5d853ec48bc4ad3d6f0ec5cdc20821550cbf3f8':
Update keyguard selector view to match UX design spec - Use new Roboto-Thin font - Add new keyguard-specific date format - Layout tweaks to keyguard selector screen. - Add smart EmergencyButton class - Add selective upper-casing of components on the display to enable later UX decision - Work around SIM state bug
* commit '57f42e855038e802c2cea4200a7cd170ea6cbf63':
Update keyguard selector view to match UX design spec - Use new Roboto-Thin font - Add new keyguard-specific date format - Layout tweaks to keyguard selector screen. - Add smart EmergencyButton class - Add selective upper-casing of components on the display to enable later UX decision - Work around SIM state bug
Calling requestLayout() during a layout pass is inadvisable, but
happens often enough in applications (especially when it occurs in
very indirect means that the application may not easily be able to
control) that we need to handle the situation without breaking. In particular,
applications that have run across this problem have had artifacts which are
difficult to debug (like things just not showing up on the screen) and
also difficult to fix. One of the side-effects of the problem is that it
leaves the view hiearchy in an unpredictable state where some views have
requested layout and are waiting to be layed out while the root view has
not received those requests, so it is never calling layout on those views.
The fix is to try to do the 'right' thing, while avoiding getting into
an inifinite loop (which could result from calling layout, which calls requestLayout(),
which causes another layout, which ...). The solution is two-tier: we handle
all requests that happen during layout by delaying them until after the current
layout is done. We then process those requests and call layout again.
If we receive more requests during that second layout, we post them to the
next frame, to allow us to finish the current one.
Issue #7155974 handle requestLayout() during layout more robustly
Change-Id: I9d13c405be28a19c86add22210e69817ddddaf8b
This change renames the widget-specific API to be more generic
to allow further disabling of keyguard-specific customizations
in the future. Currently only allows disabling widgets and the
secure camera but can now easily be extended to disable other
features we add.
Fixes bug: 7021368
Change-Id: I3934cc2e7c64e0c6d511efb86980fc38a849708d
Add a setting to globally disable Wifi display.
Fixed a bug where the wifi display broadcast receiver
was running on the wrong thread.
Removed the wifi-display QuickSettings dialog, all functionality
has been moved to Settings.
Bug: 7178216
Bug: 7192799
Change-Id: I9796baac8245d664cf28fa147b9ed978d81d8ab9
Bug #7186819
This optional OpenGL extension can be used by tiled renderers to optimize
copies from main memory to tiles memory.
Change-Id: Id4a5d64e61ad17f50e773e8104b9bf584bb65077
- Use new Roboto-Thin font
- Add new keyguard-specific date format
- Layout tweaks to keyguard selector screen.
- Add smart EmergencyButton class
- Add selective upper-casing of components on the display to enable later UX decision
- Work around SIM state bug
Bug: 7094419
Change-Id: Ic7e0f30697c14d4946372509d98ad81bf6a23c92
Previously, this flag conflicted with other text direction flags,
which can cause weird interactions across the View hierarchy,
specifically with ListView.
Also adds dumpFlags() utility to dump values of all know flags for
documentation and sanity checking.
Bug: 7189738
Change-Id: Iceb2f93f68a800e19a5889ced93abcce4932b067
Bug: 6891214
tvdpi has a density of 1.3312501 which we fail on as we assume
you can take density and multiply by 100, cast to an int, and
divide by 100f to get back to the original density. Force this
assumption to be true by truncating density
Change-Id: I0caeb7768ee002f935b41c77a5579ffeed491f82
