| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
New permission, new Intent action.
Change-Id: I1d9ba55be8f72074e29d33ad7a0a12a820bbac39
|
| |
|
|
|
|
|
|
|
| |
...to an explicit toggle to enable in Settings
Add a new permission flag, saying the permission can be automatically
granted to pre-api-23 apps. Apply this to SYSTEM_ALERT_WINDOW.
Change-Id: I24a0ceabe7e9f5e458a864d30eda2696ad14a699
|
| |
|
|
|
|
| |
Add the API. Clean up a few related things.
Change-Id: I190adad1812f36f6095b98a1001fedb94874e8b5
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since these alarms allow you to bypass the idle restrictions,
we don't want them to be so open-ended like other alarms. This
implements a policy where the alarm manager will only deliver these
types of alarms every X minutes to each application. For this
initial implementation, X is 1 minute under normal operation and
15 minutes when in idle mode.
To do this, I needed to introduce a new internal allow-while-idle
flag for system alarms, which applications can't get, and doesn't
have these new restrictions.
Also tweaked how the alarm manager handles the alarm window, so it
doesn't change if the alarm gets rescheduld; the window is now always
what as computed based on the time when the alarm was first
given to it.
Finally, fix TimeUtils to be able to correctly print times that
are > 999 days.
Change-Id: Ibad8c6a7c14b0624b54e82267be23224b4c31e84
|
| |
|
|
| |
Change-Id: I62751e93e39f90d5d2ec725586880724f3edbbc7
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
Change-Id: Ibcbc4e766400acb8cf0385f922db6ca448a652a3
|
| |
|
|
| |
Change-Id: Ib899c95de6b7bb936d2114e86bec4c5aef5f7eda
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This expands the use of EXTRA_REFERRER to be relevant anywhere,
allowing apps to supply referrer information if they want. However,
if they don't explicitly supply it, then the platform now keeps
track of package names that go with Intents when delivering them
to apps, which it can be returned as the default value.
The new method Activity.getReferrer() is used to retrieve this
referrer information. It knows about EXTRA_REFERRER, it can return
the default package name tracked internally, and it also can return
a new EXTRA_REFERRER_NAME if that exists. The latter is needed
because we can't use EXTRA_REFERRER in some cases since it is a Uri,
and things like #Intent; URI extras can only generate primitive type
extras. We really need to support this syntax for referrers, so we
need to have this additional extra field as an option.
When a referrer is to a native app, we are adopting the android-app
scheme. Since we are doing this, Intent's URI creation and parsing
now supports this scheme, and we improve its syntax to be able to build
intents with custom actions and stuff, instead of being all hung up
on custom schemes.
While doing this, fixed a problem when parsing both intent: and new
android-app: schemes with a selector portion, where we were not
respecting any scheme that was specified.
Change-Id: I06e55221e21a8156c1d6ac755a254fea386917a2
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We previously killed a process when one of its task was
swiped away in the recents UI. This had negative performance
implications for apps with multiple tasks in recents. Now we
will only kill the process if there are no more tasks associated
with it.
Changed also removes the need for the
ActivityManager.REMOVE_TASK_KILL_PROCESS since ActivityManager
will now only kill a task process if it process has no out
standing tasks.
Bug: 17305377
Change-Id: Ibc39bb328d13c7eab05c04798c2f14887923d9d4
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Keep around GET_TASKS as a permission available to apps, so apps still
think they have it and don't get all uppity because they don't.
Add a new REAL_GET_TASKS that is the actual permission now.
Plus some temporary compatibility code until everyone can transition
fromn GET_TASKS to REAL_GET_TASKS.
Change-Id: I12c1102eed24844685dcbd2fa3b612811603958f
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Improve the warning logs when setting up preferred activities
to help identify when there are issues and what they are. Also
improve the algorithm a little to still apply permissions when
resetting them and there are additional third party apps, as long
as the additional app is something like another browser and the
preferred activity being set is more specific (has a better match).
And add an example of using manifest-based preferred activities
in to ActivityTest -- and yes it DOES work! :p
Change-Id: I1ff39e03a5df6526206e0c3882085396b355d814
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Removes ActivityOptions.makeLaunchTaskBehindAnimation().
Fixes bug 16958544.
Change-Id: I2d58f4235994fe01d55b3309d0ec6f8449c5d5b8
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a new activity attribute, resumeWhilePausing, that allows an
activity specifying it to immediately start running without waiting
for the previous activity to pause. The recents activity is updated
to use this.
The implementation of this is ultimately fairly simple -- if we are
in the path of resuming such an activity, and find that we first need
to pause the existing activity, then within the activity manager we
do the regular pause flow but act like it has immediately finished
pausing right then so that we can immediately go on to the resume.
To make this clean, we tell the activity when asking it to pause that
it should not come back and tell us it is done, because we aren't in
any way waiting for it.
One potentially important change I needed to make here is the pause
callback no longer provides the saved persistent state, because we
now can't count on that callback happening. I don't think there was
really any utility in this anyway -- all modern apps will have their
save state flow happen as part of stopping, not pausing, so we'll
only capture that saved state when the stop is reported back anyway.
And since we do send the saved state back when stopping, it would
always blow away whatever we had gotten at the pause.
Finally, update the documentation for AppTask.startActivity(), and
fix the implementation handling that to be cleaner -- we need to
deal with inTask first before getting in to "oh noes add NEW_TASK
if this isn't coming from a calling activity" flow.
Change-Id: Ia1da0fac90d7bdbaafdda2e34850d795ce17a39f
|
| |
|
|
|
|
|
|
|
|
|
|
| |
It would be good to actually bring the task to the front.
Also, make the flow when inTask is provided better match what happens when
we go looking for a task on our own.
And this includes another fix that was supposed to be part of a different
change but I forgot this class is part of the framework project now.
Change-Id: I3cf05f2e585c0fd7a0dbb7c7cf9fb1655764dd93
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In application processes, monitor for when we start getting close
to the Dalvik heap limit, and ask the activity manager to try to
prune old activity instances in that case.
Add an explicit API for apps to ask that they have their own
activity instances cleaned up, if they want.
Fix some bugs in launching activities that were not correctly
applying the "multi task" behavior in the appropriate situations
of document-centric recents.
Clean up the activity manager's process removal code to all share
a common path.
Add a new "Spam" option to ActivityTests, which continually creates
new tasks, checking that the activity manager will now prune old
tasks rather than letting the app run out of RAM.
And while I was was doing this, I found problems with the path
for bringing an empty task to the foreground -- it could make
a new task instead of re-starting the root activity in the
existing task. This is fixed, and some code in the recents
UI for working around the bug is removed.
And as long as I am doing that, we now have nice hooks in to
the activity manager for AppTask to give some APIs for better
managing the task, so add those along with more tests for these
APIs in ActivityTests.
We should look at also having the activity manager try to prune
old tasks when it sees app processes being killed, to better balance
memory use across multiple processes when some processes may host
many documents. That however is for another CL...
Change-Id: I2bb81c3f92819350c868c7a7470b35817eb9bea9
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
New API Added to ActivityManager for adding an entry. See docs
there.
Repercussions:
- I hit a bug in system UI where if the thumbnail has alpha, it tries
to modify it, but thumbnails are loading immutable so crashes. Fixed
this by loading the bitmaps to be mutable.
- Improved dump output of recents; there was a lot of stuff missing.
Also split the recents dump output from the rest of the activity
output, since it can be really large.
- Added tests to the lovely ActivityTest app.
Bonus: new method on AppTask to control the exclude from recents flag.
Change-Id: I01e543db4d15320ee1701e95872fef73c116526c
|
| |
|
|
|
|
|
| |
It is wrong to turn the token into a null appWindowToken; we
need to create a new top-level token as if they had passed in null.
Change-Id: I870d8167c6ed456ea8fd58b149809ec9e0103bce
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The thumbnail returned from ActivityManager.getTaskThumbnail() now
contains either a Bitmap or a ParcelFileDescriptor that points to
a file containing a compressed Bitmap. The Recent tasks list is
now responsible for all thumbnail Bitmap caching as the activity
manager keeps only the most recent 5. This also permits low memory
devices to have many more tasks in the Recent tasks list.
As part of this CL the concept of subtasks is removed eliminating
code supporting the TaskAccessInfo and IThumbnailRetriever classes.
Fixes bug 15828934.
Change-Id: I0fd0320a1a04e3c78d79357899b83a2fff97abf2
|
| |
|
|
| |
Change-Id: I8e7b6dd092442f3870aa1a36bd2a7cd974177146
|
| |
|
|
| |
Change-Id: Iac5035f9c5884a9f9d5acb38132bb128d7a55249
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Also a few little tweaks to the ArrayMap implementation. Note that
these are fairly parallel implementations; I looked at what I could
abstract out as a base class, but there isn't really all that much without
making the resulting code more general and thus slower. If we kept
the data structure for ArraySet the same as map, where the array has
two values per entry, then they could probably share a lot of code.
I couldn't really bring myself to do that at this point, though...
Change-Id: I9e0dd8baa8e1febcc1033ecef61623ad59ce4aae
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Added equals() and hashCode() to ArrayMap to allow equals() tests
of maps with the same key/value pairs to return true.
Changed putAll() to handle the case of an empty map faster, just copying
the arrays instead of adding elements one by one.
Added to ArrayMapTests to test new equals() and copy constructor
functionality.
Issue #9299310 Optimize ArrayMap copy constructor
Change-Id: I1186a0eddd1fd53a0f380c2f3972fc1942cdf879
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a new kind of key/value mapping that stores its data
as an array, so it doesn't need to create an extra Entry object
for every mapping placed in to it. It is also optimized to reduce
memory overhead in other ways, by keeping the base object small,
being fairly aggressive about keeping the array data structures
small, etc.
There are some unit and performance tests dropped in to some
random places; they will need to be put somewhere else once I
decided what we are going to do with this for the next release
(for example if we make it public the unit tests should go in
to CTS).
Switch IntentResolver to using ArrayMap instead of HashMap.
Also get rid of a bunch of duplicate implementations of binarySearch,
and add an optimization to the various sparse arrays where you can
supply an explicit 0 capacity to prevent it from doing an initial
array allocation; use this new optimization in a few places where it
makes sense.
Change-Id: I01ef2764680f8ae49938e2a2ed40dc01606a056b
|
| |
|
|
| |
Change-Id: Ic96c2490439a78af2fb92db49b25b67b56954a20
|
| |
|
|
| |
Change-Id: Id381ee2db55b135a0734c193fce44c55ef1cdae6
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
You can now use ALL and CURRENT when sending broadcasts, to specify
where the broadcast goes.
Sticky broadcasts are now correctly separated per user, and registered
receivers are filtered based on the requested target user.
New Context APIs for more kinds of sending broadcasts as users.
Updating a bunch of system code that sends broadcasts to explicitly
specify which user the broadcast goes to.
Made a single version of the code for interpreting the requested
target user ID that all entries to activity manager (start activity,
send broadcast, start service) use.
Change-Id: Ie29f02dd5242ef8c8fa56c54593a315cd2574e1c
|
| |
|
|
|
|
| |
Gets rid of "yet another integer" confusion.
Change-Id: Id07ea7307aea7c62f0087c6663a1f1c08e2e5dee
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This allows you to, say, make a Context whose configuration
is set to a different density than the actual density of the device.
The main API is Context.createConfigurationContext(). There is
also a new API on ContextThemeWrapper that allows you to apply
an override context before its resources are retrieved, which
addresses some feature requests from developers to be able to
customize the context their app is running in.
Change-Id: I88364986660088521e24b567e2fda22fb7042819
|
| |
|
|
|
|
|
|
|
|
|
| |
- You can now use android:singleUser with receivers and providers.
- New API to send ordered broadcasts as a user.
- New Process.myUserHandle() API.
For now I am trying out "user handle" as the name for the numbers
representing users.
Change-Id: I754c713ab172494bb4251bc7a37a17324a2e235e
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Expose the existing Context.sendBroadcast() as
Context.sendBroadcastAsUser().
- Add new android:singleUser attribute for services.
- Add new INTERACT_ACROSS_USERS_FULL permission for full
system-level access to cross-user interface (allows
sendBroadcastAsUser() to send to any receiver).
- Add new INTERACT_ACROSS_USERS_FULL permission for
more restricted cross-user interaction: this is required
for android:singleUser, and allows you to use
sendBroadcastAsUser() but only to send to your own
receivers.
Change-Id: I0de88f6718e9505f4de72e3f45d29c0f503b76e9
|
| |
|
|
| |
Change-Id: Ibcc3e46a72210cf8a8e4cf5a932e2c9a7995f0f1
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
