summaryrefslogtreecommitdiffstats
path: root/tests/ActivityTests
Commit message (Collapse)AuthorAgeFilesLines
* Add test for isolated services.Dianne Hackborn2014-12-013-0/+80
| | | | Change-Id: Ibcbc4e766400acb8cf0385f922db6ca448a652a3
* Add new empty app test entry points.Dianne Hackborn2014-11-193-0/+74
| | | | Change-Id: Ib899c95de6b7bb936d2114e86bec4c5aef5f7eda
* Add Activity API to get referrer information.Dianne Hackborn2014-11-111-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix issue #17305377: Don't kill process if it still has tasks.Wale Ogunwale2014-11-041-1/+1
| | | | | | | | | | | | | | | | 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
* Fix issue #17752399: Multiple apps broken by GET_TASKS permission changeDianne Hackborn2014-10-031-1/+1
| | | | | | | | | | | | 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
* Work on issue #17628623: Need to update default preferred activities for YouTubeDianne Hackborn2014-09-231-0/+14
| | | | | | | | | | | | | | 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
* Merge "Remove deprecated (and now unused) API method." into lmp-devCraig Mautner2014-09-091-1/+1
|\
| * Remove deprecated (and now unused) API method.Craig Mautner2014-09-091-1/+1
| | | | | | | | | | | | | | | | Removes ActivityOptions.makeLaunchTaskBehindAnimation(). Fixes bug 16958544. Change-Id: I2d58f4235994fe01d55b3309d0ec6f8449c5d5b8
* | Work on issue #17357238: Recents is often slow if not used in a whileDianne Hackborn2014-09-051-1/+11
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix issue #17289876: startActivityFromRecents appears to launch the wrong taskDianne Hackborn2014-08-281-5/+1
| | | | | | | | | | | | 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
* Fix issue #16311398: Limit number of documents a process can openDianne Hackborn2014-08-264-3/+173
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix issue #17038762: Add API to add entries to the recents listDianne Hackborn2014-08-204-2/+56
| | | | | | | | | | | | | | | | | | | 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
* Fix path for handling system window with app token.Dianne Hackborn2014-08-182-0/+8
| | | | | | | 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
* Use cached thumbnails in Recent tasks.Craig Mautner2014-07-021-14/+4
| | | | | | | | | | | | | | | | 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
* Fix issue #10115327: MapCollections need to implement equalsDianne Hackborn2013-07-311-0/+59
| | | | Change-Id: I8e7b6dd092442f3870aa1a36bd2a7cd974177146
* Okay, I give in, add null key support to ArrayMap and ArraySet.Dianne Hackborn2013-07-251-10/+18
| | | | Change-Id: Iac5035f9c5884a9f9d5acb38132bb128d7a55249
* ArrayMap is great, so how about ArraySet!Dianne Hackborn2013-06-111-56/+150
| | | | | | | | | | | | 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
* Additional functionality and performance for ArrayMapChet Haase2013-06-061-0/+68
| | | | | | | | | | | | | | | 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
* New ArrayMap class.Dianne Hackborn2013-05-242-1/+310
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix test build failureAmith Yamasani2013-01-161-2/+3
| | | | Change-Id: Ic96c2490439a78af2fb92db49b25b67b56954a20
* More activity tests.Dianne Hackborn2012-09-254-3/+142
| | | | Change-Id: Id381ee2db55b135a0734c193fce44c55ef1cdae6
* Improve multi-user broadcasts.Dianne Hackborn2012-08-301-1/+2
| | | | | | | | | | | | | | | | | | | 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
* Switch public APIs to use new UserHandle class for identifying users.Dianne Hackborn2012-08-174-5/+8
| | | | | | Gets rid of "yet another integer" confusion. Change-Id: Id07ea7307aea7c62f0087c6663a1f1c08e2e5dee
* Add API to create new contexts with custom configurations.Dianne Hackborn2012-08-141-0/+33
| | | | | | | | | | | | | 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
* More mult-user API work.Dianne Hackborn2012-08-075-1/+153
| | | | | | | | | | | - 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
* Add APIs for interacting across users.Dianne Hackborn2012-08-024-12/+103
| | | | | | | | | | | | | | | | - 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
* Add new test for showing very slow animations.Dianne Hackborn2012-01-245-0/+124
| | | | Change-Id: Ibcc3e46a72210cf8a8e4cf5a932e2c9a7995f0f1
* Add APIs to remove tasks.Dianne Hackborn2011-04-122-14/+62
| | | | | | | | | | | | | | | | 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
* Rework thumbnails in activity manager.Dianne Hackborn2011-04-084-0/+158
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