On-screen navigation bar (separate from the status bar).
In Honeycomb we introduced navigation controls in the status bar, for xlarge devices without physical buttons. What about phones? The status bar is pretty cramped already, and besides, it's at the top of the display most of the time, not at the bottom where your thumb is likely to be. Enter the navigation bar. It's a new window type that appears atop almost everything (including the keyguard); the window manager subtracts its rectangle from the default visible rectangle of other windows (including the status bar and notification shade). However, it behaves (on phones) like the status bar in that applications that request fullscreen windows can get access to those pixels. Well, almost; they need cooperation from the navigation bar implementation to make the navbar disappear, just like the status bar. The current SystemUI implementation of the navigation bar on phones is still rough, but it has the basics: + back, home, and menu keys (NB: we're showing menu all the time right now because checking the api level of the package owning the top window is currently a poor indicator of whether the app requires the menu key) + it tries to stick to the same physical end of the device, regardless of device orientation (on a phone, this is the strip of land closest to the microphone) Change-Id: Ic613a3351220af0bbfbdef63e1d99cbefd5ed1c2
Loading
Please register or sign in to comment