This reverts commit f7ad855718.
After careful consideration this would prove to be a security leak to leave it in. Tasks could deliberately launch dialog activities that don't want to be seen in an unsecure setting. These would then be visible over the task background.
Change-Id: Ia7e984bc9616573af6c7772f6ea0f2dd588bb85d
New Activity methods setRecentsLabel(CharSequence) and
setRecentsIcon(Bitmap) have been added. The topmost
activity with either of these set will be returned in
RecentTaskInfo members activityLabel and activityIcon.
Fixes bug 13562992.
Change-Id: Ic15d1d27b733b892a2a940063b105ac48f1ffee5
Use the uptime while creating the battery stats history to
generate a new event indicating when the CPU is actually running.
We can do this in combination with the new event reporting when
the CPU comes awake, looking at the difference between the
uptime and elapsed time at that point to determine when it last
when to sleep.
Also use this information to generate a new set of aggregated
states, the uptime caused by each wake reason.
Finally use new radio down timestamp to adjust the times we
compute for radio use. Note that this information is not (yet)
being used to adjust how these are recorded in the history.
Change-Id: I723b3b526c8e7d64de0cac9d1193e04132d5a3e4
If the bottommost fullscreen window of a task has FLAG_SHOW_WHEN_LOCKED
set then show all windows of the task that are above that window.
Fixes bug 13558398.
Change-Id: Ied8ada54efbb079eaf375470b2eae749e5551c24
If a view has a non-zero ID that is not defined in resources (i.e. has been
set pragmatically), the calls to Resources.getResourcePackageName() and
Resources.getResourceEntryName() result in a log warning:
No package identifier when getting name for resource number 0x00000001
Fix this by not attempting to resolve the package & name when there is
none.
Change-Id: Id88a61539fffb36187da7911f8e8a42d5a1bb951
Rename @hidden Notification.kind -> category, and flesh out
shared values. Now a single value.
Update framework references, remove unused SystemUpdateService
magic value unused since 2012.
Change-Id: If06d19ff3a8c3125fca1457f5d3c665e2939c66c
Migrate existing framework usages of Vibrator.vibrate to use
the new overload with an explicit stream hint. This prevents
them from being blocked by rules targeting the unspecified stream.
For calls that pass the existing appops check in VibrateService,
pass streamHint down to the input device vibrator so we don't lose
the signal, but leave it up to InputManager to decide what to do
with it - currently unused.
Change-Id: I65c944e4010edea29a412bf57d8d7d3b8098b746
Bug: 11997581
- ignore suggested dimensions
- when orientation changes, scale up wallpaper if
it doesn't fill the whole screen, or scale back to
original size if not necessary
Change-Id: I75b7519a105d4097bf7a35cd8af61fc40f45f8fb
(cherry picked from commit 824a4b5ea4)
Backup/restore now supports app widgets.
An application involved with app widgets, either hosting or publishing,
now has associated data in its backup dataset related to the state of
widget instantiation on the ancestral device. That data is processed
by the OS during restore so that the matching widget instances can be
"automatically" regenerated.
To take advantage of this facility, widget-using apps need to do two
things: first, implement a backup agent and store whatever widget
state they need to properly deal with them post-restore (e.g. the
widget instance size & location, for a host); and second, implement
handlers for new AppWidgetManager broadcasts that describe how to
translate ancestral-dataset widget id numbers to the post-restore
world. Note that a host or provider doesn't technically need to
store *any* data on its own via its agent; it just needs to opt in
to the backup/restore process by publishing an agent. The OS will
then store a small amount of data on behalf of each widget-savvy
app within the backup dataset, and act on that data at restore time.
The broadcasts are AppWidgetManager.ACTION_APPWIDGET_RESTORED and
ACTION_APPWIDGET_HOST_RESTORED, and have three associated extras:
EXTRA_APPWIDGET_OLD_IDS
EXTRA_APPWIDGET_IDS
EXTRA_HOST_ID [for the host-side broadcast]
The first two are same-sized arrays of integer widget IDs. The
_OLD_IDS values are the widget IDs as known to the ancestral device.
The _IDS array holds the corresponding widget IDs in the new post-
restore environment. The app should simply update the stored
widget IDs in its bookkeeping to the new values, and things are
off and running. The HOST_ID extra, as one might expect, is the
app-defined host ID value of the particular host instance which
has just been restored.
The broadcasts are sent following the conclusion of the overall
restore pass. This is because the restore might have occurred in a
tightly restricted lifecycle environment without content providers
or the package's custom Application class. The _RESTORED broadcast,
however, is always delivered into a normal application environment,
so that the app can use its content provider etc as expected.
*All* widget instances that were processed over the course of the
system restore are indicated in the _RESTORED broadcast, even if
the backing provider or host is not yet installed. The widget
participant is responsible for understanding that these are
promises that might be fulfilled later rather than necessarily
reflecting the immediate presentable widget state. (Remember
that following a cloud restore, apps may be installed piecemeal
over a lengthy period of time.) Telling the hosts up front
about all intended widget instances allows them to show placeholder
UI or similarly useful information rather than surprising the user
with piecemeal unexpected appearances.
The AppWidgetProvider helper class has been updated to add a new
callback, onRestored(...), invoked when the _RESTORED broadcast
is received. The call to onRestored() is immediately followed by
an invocation of onUpdate() for the affected widgets because
they will need to have their RemoteViews regenerated under the
new ID values.
Bug 10622506
Bug 10707117
Change-Id: Ie0007cdf809600b880d91989c00c3c3b8a4f988b
