For now, each time the dead zone captures a touch, it will
flash to let you know that's what happened. We should
probably turn this off before shipping.
Note also that this currently only expands the navbar on
ACTION_DOWN elsewhere in the UI (because this is the only
time ACTION_OUTSIDE is generated); this isn't perfect and
we'll need to do some mucking about with the input system to
get information about ongoing drags or additional pointers
down, but this CL is a good start and introduces the general
mechanism for expanding and contracting the dead zone.
Change-Id: I43e63aed1e541fd07d83fde4d66bcb5be89b69d2
The framework is no longer letting us skate by without a
default (unqualified) for of each resource; in particular,
the land/port aspect of the configuration appears to be
binding much later than it used to.
Bug: 6937365
Change-Id: I6bf72c76e707548168fefa9466dc196ffde33ab3
This fixes a few recent regressions caused by other bug fixes:
- add new flags to animateCollapse() so we can selectively close panels. Fixes regression caused by attempt to close recent apps from startAssistActivity() which had the side effect of closing the search panel before the animation completes.
- adds tuneable holdoff delay for responding to home key press.
- minor tweaks to MultiWaveView animations.
Change-Id: Ia48434b8d59e7b0290a5e9783960c2f684068218
- getting rid of blue glow (5529032)
- moving app icon position
- show message if there are no recent apps (5533332)
- fixing rare IllegalStateException on orientation change (5584344)
Change-Id: I2210e584957869c8f02339e6841daf39364a9dad
- 20fps improvement using software rendering
- 10fps improvement using hardware rendering
- in sw mode, rendering recents background in the recent items themselves and using a bitmap cache to draw individual items (gives perf gains for sw mode)
- in sw and hw mode, no longer doing a fade on the recents scroll view (gives perf gains for hw mode) - instead we draw a black gradient where we would normally fade
- fading recents & notifications immediately when swiped
- removing unused code
Change-Id: I908e2a25b89c9dfbf9b8c8f3810fa43064261b33
This means the navbar will either be at the bottom (portrait
and reverse portrait) or the right (landscape and seascape)
irrespective of the physical bottom of the device.
Change-Id: Ib51cab22f246785c9cebcc688bcdb848eb776361
For devices with minimum width between 600 and 720 dp, show
only 3 icons (and then, only in portrait). All other
configurations will show 5.
Bug: 4501374
Change-Id: I88168560fc2876c26cd3eb57f2db0b0cfe8b4fdd
The PhoneWindowManager is now responsible for determing this,
since it needs to do this before we can generate the configuration
since we need to take into account the system bar size we will use.
Also the Display should now report the screen height without
including the system bar.
Change-Id: I82dfcc5e327e4d13d82c373c6c870f557a99b757
This will eventually be replaced by something else, probably
in Configuration, that allows the WM to tell everyone
(including the status bar) whether there exist hardware
home/back/etc. keys.
Change-Id: I21e9629ed43de4a944ad75e5b9d6d4ada8aba23f
There is now one SystemUIService, which starts the status bar service.
Pretty soon there will be other things running in here too. This way
we don't need to have each of them started by something individually.
This also moves the choice between tablet and phone status bar into
SystemUI.apk, which seems like a much better place for it.
Change-Id: Ib69ef2f43d648764f8dbb52008f5d036a1ee07d9
