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
* provide placeholder UI showing backup/restore start/stop/timeout
* don't kill the progress UI in mid stream
* tidy up the pax extended header data writing a little
Change-Id: Ife0cb78e3facb541d8327f1d5ca5fe77faa6cbca
Adds a really crappy UI for toggling compat mode.
Persists compat mode selection across boots.
Turns on compat mode by default for newly installed apps.
Change-Id: Idc83494397bd17c41450bc9e9a05e4386c509399
* commit '0fe56853fd88c34aba37b04be256a0e51c1bbff7':
Move / copy some framework and systemui resources from xlarge to large. The status bar now comes up on large tablets.
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
Views requesting lights out mode will cause the navbar to
disappear (this is useful for viewing videos/photos/etc
using every pixel of the screen).
But there's a catch: any user activity at all will cause the
lights to come back on and the navbar to return.
Change-Id: I535ed3ba9ae7fab3282c402be256add765395b6f
This is the basic infrastructure for pulling a full(*) backup of the
device's data over an adb(**) connection to the local device. The
basic process consists of these interacting pieces:
1. The framework's BackupManagerService, which coordinates the
collection of app data and routing to the destination.
2. A new framework-provided BackupAgent implementation called
FullBackupAgent, which is instantiated in the target applications'
processes in turn, and knows how to emit a datastream that contains
all of the app's saved data files.
3. A new shell-level program called "bu" that is used to bridge from
adb to the framework's Backup Manager.
4. adb itself, which now knows how to use 'bu' to kick off a backup
operation and pull the resulting data stream to the desktop host.
5. A system-provided application that verifies with the user that
an attempted backup/restore operation is in fact expected and to
be allowed.
The full agent implementation is not used during normal operation of
the delta-based app-customized remote backup process. Instead it's
used during user-confirmed *full* backup of applications and all their
data to a local destination, e.g. via the adb connection.
The output format is 'tar'. This makes it very easy for the end
user to examine the resulting dataset, e.g. for purpose of extracting
files for debug purposes; as well as making it easy to contemplate
adding things like a direct gzip stage to the data pipeline during
backup/restore. It also makes it convenient to construct and maintain
synthetic backup datasets for testing purposes.
Within the tar format, certain artificial conventions are used.
All files are stored within top-level directories according to
their semantic origin:
apps/pkgname/a/ : Application .apk file itself
apps/pkgname/obb/: The application's associated .obb containers
apps/pkgname/f/ : The subtree rooted at the getFilesDir() location
apps/pkgname/db/ : The subtree rooted at the getDatabasePath() parent
apps/pkgname/sp/ : The subtree rooted at the getSharedPrefsFile() parent
apps/pkgname/r/ : Files stored relative to the root of the app's file tree
apps/pkgname/c/ : Reserved for the app's getCacheDir() tree; not stored.
For each package, the first entry in the tar stream is a file called
"_manifest", nominally rooted at apps/pkgname. This file contains some
metadata about the package whose data is stored in the archive.
The contents of shared storage can optionally be included in the tar
stream. It is placed in the synthetic location:
shared/...
uid/gid are ignored; app uids are assigned at install time, and the
app's data is handled from within its own execution environment, so
will automatically have the app's correct uid.
Forward-locked .apk files are never backed up. System-partition
.apk files are not backed up unless they have been overridden by a
post-factory upgrade, in which case the current .apk *is* backed up --
i.e. the .apk that matches the on-disk data. The manifest preceding
each application's portion of the tar stream provides version numbers
and signature blocks for version checking, as well as an indication
of whether the restore logic should expect to install the .apk before
extracting the data.
System packages can designate their own full backup agents. This is
to manage things like the settings provider which (a) cannot be shut
down on the fly in order to do a clean snapshot of their file trees,
and (b) manage data that is not only irrelevant but actively hostile
to non-identical devices -- CDMA telephony settings would seriously
mess up a GSM device if emplaced there blind, for example.
When a full backup or restore is initiated from adb, the system will
present a confirmation UI that the user must explicitly respond to
within a short [~ 30 seconds] timeout. This is to avoid the
possibility of malicious desktop-side software secretly grabbing a copy
of all the user's data for nefarious purposes.
(*) The backup is not strictly a full mirror. In particular, the
settings database is not cloned; it is handled the same way that
it is in cloud backup/restore. This is because some settings
are actively destructive if cloned onto a different (or
especially a different-model) device: telephony settings and
AndroidID are good examples of this.
(**) On the framework side it doesn't care that it's adb; it just
sends the tar stream to a file descriptor. This can easily be
retargeted around whatever transport we might decide to use
in the future.
KNOWN ISSUES:
* the security UI is desperately ugly; no proper designs have yet
been done for it
* restore is not yet implemented
* shared storage backup is not yet implemented
* symlinks aren't yet handled, though some infrastructure for
dealing with them has been put in place.
Change-Id: Ia8347611e23b398af36ea22c36dff0a276b1ce91
* commit '37c077d3dc32cd42c145072b671a6d53563b0156':
Move / copy some framework and systemui resources from xlarge to large. The status bar now comes up on large tablets.
* commit '81faa44c48911e4a63adaa1c92c5a40ea3c58ffb':
Move / copy some framework and systemui resources from xlarge to large. The status bar now comes up on large tablets.
Notifications on phones should look much more like Honeycomb
now, including large icon and veto support.
And less crashing.
Bug: 4322305
Change-Id: Ibde6f66fbae1c8d3167085f7b0fd79118485f05c
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
