| 4b84606c21b29d716f2e5b8821c28d92f1dd25bd |
23-Feb-2017 |
Jorim Jaggi <jjaggi@google.com> |
Implement new splash screen API
Test: mmm frameworks/base/tests/ActivityTests, launch
CustomSplashscreenActivity
Test: android.server.android.server.cts.SplashscreenTests
Bug: 37252694
Change-Id: I9a5bc19b8f63312e682e536500411e4ff4639f88
ustomSplashscreenActivity.java
|
| 8f4fe6eccbc3849686f08389cb5868f2d59f5fbb |
14-Mar-2017 |
Jorim Jaggi <jjaggi@google.com> |
When snapshots are disabled, fill it with single color.
Test: Launch DisableScreenshotsActivity, go to recents, make sure
content is blue. Reopen activity from home, make sure starting
window is blue.
Bug: 31339431
Change-Id: I29689774c3cdcb784d8f5bfa4f947a6f35b91e01
isableScreenshotsActivity.java
|
| 0fe7ce968bc7f0eff64f08e2d51c8b1e6b4a6fc8 |
22-Feb-2017 |
Jorim Jaggi <jjaggi@google.com> |
Add API to disable snapshotting of activities
Test: runtest frameworks-services -c
com.android.server.wm.TaskSnapshotControllerTest
Test: Launch DisableScreenshotsActivity, go to recents, make sure
content is white.
Bug: 31339431
Change-Id: I329925d2fca389e561da3389a67fe888b5bb1033
isableScreenshotsActivity.java
|
| e4de5a0d3b6e0c897c1cea0912b58e11db962365 |
23-Sep-2015 |
Xiaohui Chen <xiaohuic@google.com> |
Cleanup OWNER references.
Bug: 19913735
Change-Id: I2150c6baaab80fe11312e4401394a2a8da52e595
ctivityTestMain.java
|
| c7b57b1e65b487defad4967cf42cf076b499cbee |
10-Aug-2015 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #23037899: Support for Battery Optimization permission + Dialog
New permission, new Intent action.
Change-Id: I1d9ba55be8f72074e29d33ad7a0a12a820bbac39
ctivityTestMain.java
|
| 1958e5e7870579337f1d1d3e6c6fae096ba3abb9 |
13-Jun-2015 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #21813831: Need API for asking to be added to power whitelist
Add the API. Clean up a few related things.
Change-Id: I190adad1812f36f6095b98a1001fedb94874e8b5
ctivityTestMain.java
|
| 3d1933c45fe9ba2389ebd166d96abeceab1971d1 |
11-Jun-2015 |
Dianne Hackborn <hackbod@google.com> |
Implement some control over ALLOW_WHILE_IDLE alarms.
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
ctivityTestMain.java
larmSpamReceiver.java
|
| 67ba2c7fa25a635c640956ff3a5e64164cb23396 |
05-Jun-2015 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #21572679: API Review: ActivityOptions, usage time report
Change-Id: I62751e93e39f90d5d2ec725586880724f3edbbc7
rackTimeReceiver.java
|
| e5c42621095a12e7d22ca5ab871dacd28c9bff41 |
20-May-2015 |
Dianne Hackborn <hackbod@google.com> |
Improve reporting to apps of transaction too large failures.
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
ctivityTestMain.java
|
| b5a380d409a1431a38db978864b9d85b689e3cce |
21-May-2015 |
Dianne Hackborn <hackbod@google.com> |
Add API to track usage time of apps.
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
ctivityTestMain.java
rackTimeReceiver.java
|
| 875e464e362c1e5527c5830c107c7ef84ecfbf0d |
02-Dec-2014 |
Dianne Hackborn <hackbod@google.com> |
Add test for isolated services.
Change-Id: Ibcbc4e766400acb8cf0385f922db6ca448a652a3
ctivityTestMain.java
solatedService.java
|
| 4f0e4a9ada1192e103d43409d83e177608571c68 |
19-Nov-2014 |
Dianne Hackborn <hackbod@google.com> |
Add new empty app test entry points.
Change-Id: Ib899c95de6b7bb936d2114e86bec4c5aef5f7eda
mptyService.java
tartEmpty.java
|
| 85d558cd486d195aabfc4b43cff8f338126f60a5 |
04-Nov-2014 |
Dianne Hackborn <hackbod@google.com> |
Add Activity API to get referrer information.
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
ctivityTestMain.java
|
| d54b578e47fb410c776bb3a4272c2c523153f657 |
24-Oct-2014 |
Wale Ogunwale <ogunwale@google.com> |
Fix issue #17305377: Don't kill process if it still has tasks.
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
ctivityTestMain.java
|
| 345d4f4f14038c2225cd599f9c432b25e572dc2c |
09-Sep-2014 |
Craig Mautner <cmautner@google.com> |
Merge "Remove deprecated (and now unused) API method." into lmp-dev
|
| 0321573fa7583cd2ac4ece015c2eb784e3b24eb8 |
09-Sep-2014 |
Craig Mautner <cmautner@google.com> |
Remove deprecated (and now unused) API method.
Removes ActivityOptions.makeLaunchTaskBehindAnimation().
Fixes bug 16958544.
Change-Id: I2d58f4235994fe01d55b3309d0ec6f8449c5d5b8
ctivityTestMain.java
|
| a4e102ee580282dc7abeb22f4a025813e53b9431 |
05-Sep-2014 |
Dianne Hackborn <hackbod@google.com> |
Work on issue #17357238: Recents is often slow if not used in a while
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
ctivityTestMain.java
|
| d7c9289f935992f4ae2fc032747f9e04bb86a7d0 |
28-Aug-2014 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #17289876: startActivityFromRecents appears to launch the wrong task
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
ctivityTestMain.java
|
| 89ad456ea49cb62615ebdcac83a2515743bbe5fa |
25-Aug-2014 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #16311398: Limit number of documents a process can open
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
ctivityTestMain.java
ocActivity.java
pamActivity.java
|
| aec68bb89fe614181a20eb97340149406218ce2f |
21-Aug-2014 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #17038762: Add API to add entries to the recents list
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
ctivityTestMain.java
|
| 15ed2754a308546a54ab1061b4e365d6fe9b898d |
19-Aug-2014 |
Dianne Hackborn <hackbod@google.com> |
Fix path for handling system window with app token.
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
ctivityTestMain.java
|
| c0ffce5ddd6446f1d46a49cdfaeda4a2ce408e1d |
01-Jul-2014 |
Craig Mautner <cmautner@google.com> |
Use cached thumbnails in Recent tasks.
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
ctivityTestMain.java
|
| 8b7bc13e217034e0ddd00f9033463190f50dce88 |
01-Aug-2013 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #10115327: MapCollections need to implement equals
Change-Id: I8e7b6dd092442f3870aa1a36bd2a7cd974177146
rrayMapTests.java
|
| 62d708f4dd8e2a8554df4967837df9896efeff7c |
26-Jul-2013 |
Dianne Hackborn <hackbod@google.com> |
Okay, I give in, add null key support to ArrayMap and ArraySet.
Change-Id: Iac5035f9c5884a9f9d5acb38132bb128d7a55249
rrayMapTests.java
|
| 21ab6f49910a6f319bc7b9d3964086cb1ffe09d0 |
11-Jun-2013 |
Dianne Hackborn <hackbod@google.com> |
ArrayMap is great, so how about ArraySet!
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
rrayMapTests.java
|
| f4130cf35fa128e36f96e55955d4f5db86197e4a |
07-Jun-2013 |
Chet Haase <chet@google.com> |
Additional functionality and performance for ArrayMap
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
rrayMapTests.java
|
| f4bf0ae2a7c2d9d92c5c8abdb82baa53b4c9ccda |
21-May-2013 |
Dianne Hackborn <hackbod@google.com> |
New ArrayMap class.
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
ctivityTestMain.java
rrayMapTests.java
|
| 45c0924fbbb2bdd38b5d154e2bc440abda4381c4 |
17-Jan-2013 |
Amith Yamasani <yamasani@google.com> |
Fix test build failure
Change-Id: Ic96c2490439a78af2fb92db49b25b67b56954a20
ctivityTestMain.java
|
| 3992645bf333c56669ef2fa19c26b2947884a4f3 |
25-Sep-2012 |
Dianne Hackborn <hackbod@google.com> |
More activity tests.
Change-Id: Id381ee2db55b135a0734c193fce44c55ef1cdae6
ctivityTestMain.java
erviceUserTarget.java
ingleUserService.java
|
| 5ac72a29593ab9a20337a2225df52bdf4754be02 |
30-Aug-2012 |
Dianne Hackborn <hackbod@google.com> |
Improve multi-user broadcasts.
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
ctivityTestMain.java
|
| 79af1dd54c16cde063152922b42c96d72ae9eca8 |
17-Aug-2012 |
Dianne Hackborn <hackbod@google.com> |
Switch public APIs to use new UserHandle class for identifying users.
Gets rid of "yet another integer" confusion.
Change-Id: Id07ea7307aea7c62f0087c6663a1f1c08e2e5dee
ctivityTestMain.java
ingleUserProvider.java
ingleUserReceiver.java
serTarget.java
|
| 756220bd1912535840388a6743830d2e59ad4964 |
15-Aug-2012 |
Dianne Hackborn <hackbod@google.com> |
Add API to create new contexts with custom configurations.
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
ctivityTestMain.java
|
| 7d19e0242faac8017033dabb872cdf1542fa184c |
08-Aug-2012 |
Dianne Hackborn <hackbod@google.com> |
More mult-user API work.
- 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
ctivityTestMain.java
ingleUserProvider.java
ingleUserReceiver.java
serTarget.java
|
| b4163a6e12ee7100c758c6d3d062ade1f2843fce |
03-Aug-2012 |
Dianne Hackborn <hackbod@google.com> |
Add APIs for interacting across users.
- 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
ctivityTestMain.java
ingleUserService.java
serTarget.java
|
| 8a59b7f95f84ecc1f961a57d013ac68743c35d74 |
09-Jan-2012 |
Dianne Hackborn <hackbod@google.com> |
Add new test for showing very slow animations.
Change-Id: Ibcc3e46a72210cf8a8e4cf5a932e2c9a7995f0f1
ctivityTestMain.java
|
| 0c5001d776d56bae02a5cc2663286a125d99bc5e |
13-Apr-2011 |
Dianne Hackborn <hackbod@google.com> |
Add APIs to remove tasks.
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
ctivityTestMain.java
|
| f26fd99a7c2f554b0297760bb66336473c7db61f |
09-Apr-2011 |
Dianne Hackborn <hackbod@google.com> |
Rework thumbnails in activity manager.
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
ctivityTestMain.java
|