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
The status bar figures out how tall it needs to be by
subtracting 720 (for 720p HDMI output) from the display
height. However, if the display is in the process of
rotating to portrait when HDMI is attached (or for whatever
other reason dispatches the HDMI_PLUGGED_STATE before the
display has been rotated to landscape) this computation will
be wrong.
The quick fix is to compute the status bar height as
shortSide - 720 rather than height - 720.
Bug: 4284690
Change-Id: I3715264a9e32af1299777ccdbdc22ca60926cc79
The onUpgrade path was upgrading the database version to 65, but the
current version was marked as 64. That led to the database being
upgraded to 65 and then wiped because it didn't match 64.
This was introduced in HC change 54d068ec6af0ee6d261a135400efe6816c6f5ffe
Bug: 4319406
Change-Id: Ib6efcf34e820948d23d3a2b8ef3afc9012a93c22
This removes the old non-public C++ API for TTS
engines and replaces it with a Java API.
The new API is still @hidden, until it has been approved.
Bug: 4148636
Change-Id: I7614ff788e11f897e87052f684f1b4938d539fb7
You can remove sub-tasks inside of a task, or an entire task.
When removing an entire task, you can have its process killed
as well.
When the process is killed, any running services will get an
onTaskRemoved() callback for them to do cleanup before their
process is killed (and the service possibly restarted).
Or they can set a new android:stopWithTask attribute to just
have the service automatically (cleanly) stopped at this point.
Change-Id: I1891bc2da006fa53b99c52f9040f1145650e6808
We now only keep a thumbnail for the task, not for each
activity. However if you use FLAG_ACTIVITY_CLEAR_WHEN_TASK_RESET,
we will make a new secondary thumbnail for that series of
activities. There is a new API for the app to get these
secondary thumbnails.
Also set a default thumbnail size for non-xlarge screens
so we have thumbnails on phones. (We need some smarter
code in the platform for computing the actual thumbnail
dimensions of the current device). And add a test app
to show recent tasks + thumbnails.
Change-Id: Ic36759f6635522118a2cb7f156662229a610c492
This replaces an icon which said 3g and as such was
useful. This needs to be replaced with an official
icon but is better than the current version.
bug: 4260327
Change-Id: I59674464d510ae205020008383d60a984db2c9d0
