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
As per API council request, factory methods should be used instead of using
boolean.
Bug: 21343772
Change-Id: Ia0889e46916f4ed7edb942217880cdf9c27771c2
This flag indicates if scan was successful and results were
updated. It will be set to false if a scan is not performed
(intentionally) or if it failed to produce any results.
Bug: 20642015
Change-Id: I06a1fdd684932db68891ee28d5a049980f483f0f
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
It was deprecated as part of the Apache deprecation, however it is used
by ConnectivityManager.getLinkProperties() and .getDefaultProxy().
The alternatives (e.g. java.net.Proxy) do not offer a complete
replacement as they lack certain fields (e.g. PAC URL).
Bug:21274137
Change-Id: I99163a2611a738f337fb9907349ef6255dbed6d6
...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
- Adds an ActionMode.snooze(int) API.
- Clients call this to hide the floating toolbar on DOWN touch event.
- This is called repeatedly as a snooze timeout will re-show the
toolbar.
- ActionMode.snooze(0) will "wake" the toolbar, reshowing it.
- Clients call this to re-show the toolbar on UP touch event.
- This CL also adds code to hide the toolbar when the "content rect"
is changing.
Bug: 20148125
Change-Id: If5a9a15f72c73cad8ca01a4328a58570b3e29f66
