Also rework how we transfer AssistContent and AssistStructure
to the assistant, so they are delivered as completely separate
objects rather than the kludgy bundling them in the assist
data thing.
Change-Id: Ib40cc3b152bafeb358fd3adec564a7dda3a0dd1d
If the app tried to do various things with too much data --
starting an activity, starting a service, sending a broadcast --
this would fairly silently fail with little indication of what
was going on. Fix this in two ways:
- Now when the native code generates a TransactionTooLargeException,
it may include an additional message in it telling you how much
data was in the parcel being sent, to help you understand why
this happening.
- In all the framework code paths where we call to the system and
may fail, convert these failures into a a runtime exception and
rethrow them back to the app so that it will clearly get the
above message.
Change-Id: I745159b97d3edb6fca86aa09cbc40c1f15a7d128
This adds a new ActivityOption for the caller to ask the
system to track the time the user is in the app it launches,
delivering the result when they are done.
The time interval tracked is from when the app launches the
activity until the user leaves that app's flow. They are
considered to stay in the flow as long as new activities
are being launched or returned to from the original flow,
even if they cross package or task boundaries. For example,
if the originator starts an activity to view an image, and
while there the user selects to share, which launches gmail
in a new task, and they complete the share, the time during
that entire operation will be included.
The user is considered to complete the operation once they
switch to another activity that is not part of the tracked
flow. For example, use the notification shade, launcher, or
recents to launch or switch to another app. Simply going
in to these navigation elements does not break the flow
(although the launcher and recents stops time tracking of
the session), it is the act of going somewhere else that
completes the tracking.
The data is delivered to the app through a PendingIntent,
which includes the total time the app was in the flow along
with a time break-down by app package.
Change-Id: If1cf8892d422c52ec5042eba0e15a8e7e8f83abf
Previously getHomeActivity() returned the topmost home activity
independent of which user was currently running. That defeated the
purpose of the method. This fix returns the home activity of the
current user or null if one has not yet been created.
Also remove some cruft that accumulated.
Fixes bug 21055376.
Change-Id: Ic1d58129aedbe3624f8a9d12c05c84674687b0a4
We have APIs for a DO/PO to fix a permission in a granted or
denied state in which the user cannot manage this permission
through the UI. However, there is no way to go back to the
default state in which the user gets to choose the permission
grant state.
Change-Id: I2562a1d8b1385cd740b44812844ef14c895c2902
First, when parceling a notification with no small icon:
Well, you shouldn't attempt to do this anyway, since NoMan
will reject a notification without a valid smallIcon. But
setServiceForeground parcels up the Notification on its own
before handing it off to NoMan, so it will crash on an
invalid small icon. (In general, parceling code should never
ever crash, even if the object is in an undesirable state.)
And when build()ing a notification: Same thing---don't build
a notification with no icon; you're going to have a bad
time. But maybe you're going to fix it before you hand it
off to NoMan. Or maybe it's just one page of a wearable
notification, so it doesn't really need its own icon. Either
way, Notification shouldn't crash.
Bug: 21286186
Bug: 21298403
Change-Id: Ie482cde0a3afe3aaabf07be0536551b8e4bceba0
...from text nodes in WebView
Add a new explicit API for setting the text style information associated
with a view structure.
Also, how about some documentation!
Change-Id: Ia948b2d66382b973d0d00a67172a281ad55ce592
To follow the correct semantics for when restricts due to
device idle can be applied, power manager need to know about
uid process states like net policy so that it can allow
wake locks from apps that are in the foreground.
Since this is being added to a second place, I reworked things
so that the activity manager now keeps track of per-uid process
states and allows apps to register to listen to those, rather
than having to track lower-level process states and transform
them into an overall uid state. Both net policy and power
manager use this new facility.
Change-Id: I77359164c40d0f36fe1ef296dd9f9c3062431148
Reverts commits 92dd1abef4,
18795a2299, and
ac6a3a5e9d which make-up
changes required for backing-up and restoring recent
tasks from one device to another.
The implementation had too many unresolved issues including
the ordering of the restored recent tasks which was depending
on when the task package is installed on the new device that
puts the restored recents list out of order compared to the
old device.
Bug: 15986349
Bug: 19014377
Bug: 20763296
Change-Id: I06fd35a43036ef0b7260cf4db9c42890df63b95d
And you may ask yourself: what is that beautiful icon?
And you may ask yourself: where does that API go to?
And you may ask yourself: is it a resource? is it a Bitmap?
And you may say to yourself: my god, what have I done
(This patch fixes a number of bugs in the initial
implementation, but other than that, it's the same as it
ever was.)
Bug: 18568715
Bug: 21141842
Change-Id: I1d3f9427abd7f0bb57e533fcfac708851ff644b6
Explicitly call out that even if the backend is in an undefined state
(such as no authenticated account, so there is by definition no work
that can be done here), the transport should return TRANSPORT_OK in
response to initializeDevice(). Error returns from that method must
only be used to indicate that the initialize should be *retried*.
Bug 21136957
Change-Id: I41ad115b92c16092b4d931d9c554a44b77945359
Uri provides a stronger guarantee of well-formedness and lets apps do
nice extra things like specifying scheme etc. without twisting any
expectations.
Bug: 20820034
Change-Id: Ia6bbedb74765444920b667d643fb7e1eb6a7292b
And you may ask yourself: what is that beautiful icon?
And you may ask yourself: where does that API go to?
And you may ask yourself: is it a resource? is it a Bitmap?
And you may say to yourself: my god, what have I done
Bug: 18568715
Change-Id: I4377b311c538bd1cf36b3fba22326bae81af40c9
This moves the non-public API classes backing Android Keystore from
android.security to android.security.keystore, a package specially
created for Android Keystore.
Bug: 18088752
Change-Id: Ibf04d6a26c54d310b0501fc5e34f37b1176324ad
The access mock location is no longer a runtime permission. It is a
signature protected one that apps cannot get but the fact they request
it means they want to inject location into the system. Now the user
gets to choose the current mock location app in developer options from
the apps that request the mock location permission. The access to mock
location is no longer guarded by the permisson but from a new app op
which is off by default and the settiings UI sets it to enabled only
for the currently selected mock location app.
bug:21078873
Change-Id: I19e3f9dc7c7de82eab46b30fec1abfbca54a0e59
- The mechanism to stop windows drawing while window animator was
animating was somehow flaky. It relied on the fact that the client
would call relayout() whenever the animating state changed. This is
mostly the case, but not for lockscreen animations. Instead, we now
use a push model, where window manager tells the app that the state
has changed.
- In addition, it only stopped drawing if that window was animating,
but then only resumed drawing after all windows have finished
animating. Now, we do this per window, so we only stop drawing for
windows that are currently animating.
- We resume the top activity now at the very beginning of the
unlocking sequence. This gives the app a chance to draw a frame
before the user sees anything. If it's to slow, then we just use the
outdated framebuffer.
Bug: 19964562
Change-Id: Ifef8abd189a3146d854b81b9b948861e4d38c155
In the original implementation, we would only save the state if the
activity was "!isFinishing()". That was abstracted into a method
that returned whether we should save state. However, the "!" wasn't
removed. D'oh.
Bug: 20860094
Change-Id: I8827cb265f2e7fb911f5d110c56e464aa092bfe7
