| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
Bug: 22701182
Change-Id: I2ec56c55c49401f2f213bbd318e867fd73b37672
|
|
|
|
|
|
|
|
| |
Use stop user callback to wait for AM.stopUser to complete
if -w flag is passed to adb shell am stop-user
bug: 22599411
Change-Id: I8adbfdbb1ba69a88a67431da65f0a85035587c2d
|
|
|
|
|
|
|
|
|
| |
Added Context.sendBroadcastMultiplePermissions(Intent intent, String[]
receiverPermissions) method, which allows an array of required permissions
to be enforced.
Bug: 21852542
Change-Id: I27c9130e8f004b428452501ebc8a36aabde1f343
|
|
|
|
|
|
| |
bug:22248271
Change-Id: I3a47ae9a112ba7d88b421fcb5f9651d1168ba7a5
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Perform app op check in addition to the permisison check for all four
paltform components - activities, content providers, broadcast receivers,
services - if they are guarded by a permssion that has an associated app
op. This ensures that legacy apps will behave correctly if the permission
of the caller has been revoked, i.e. the app op for that permission was
disabled.
bug:22199666
Change-Id: Ia22d1c38d58b3cd6aabdc655cb7c7bddd85da7a2
|
|
|
|
|
|
|
| |
ActivityManager#getPackageImportance()
Bug:22055550
Change-Id: I1e732e95698daf44bcb223cafde3d3c22746d232
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Issue #21814207: AlarmManager.setAndAllowWhileIdle should also allow wake locks.
Introduce a whole new infrastructure for providing options when
sending broadcasts, much like ActivityOptions. There is a single
option right now, asking the activity manager to apply a tempory
whitelist to each receiver of the broadcast.
Issue #21814212: Need to allow configuration of alarm manager parameters
The various alarm manager timing configurations are not modifiable
through settings, much like DeviceIdleController. Also did a few
tweaks in the existing DeviceIdleController impl.
Change-Id: Ifd01013185acc4de668617b1e46e78e30ebed041
|
|
|
|
|
|
|
|
|
|
|
| |
extras as ArrayList instead of Array.
BUG: 21757911
Change-Id: I7e2a9c81ad4606a8aba90ea4820ba0732a1c8749
modified: src/com/android/commands/am/Am.java
On branch handles_array_list
Changes to be committed:
modified: src/com/android/commands/am/Am.java
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds a send-trim-memory command to the ActivityManager to allow
for better debugging&testing.
The command is
adb shell am send-trim-memory [--user <USER_ID>] <PROCESS> <LEVEL>
whereas LEVEL can be one of the following:
[HIDDEN|RUNNING_MODERATE|BACKGROUND|RUNNING_LOW|MODERATE|
RUNNING_CRITICAL|COMPLETE]
Bug: 21633189
Change-Id: I7a41ce02c3c9043ffd3e5aaa791f7b7306a9de49
|
|
|
|
|
|
|
| |
Change to setAppInactive and isAppInactive in a few places.
Bug: 20823737
Change-Id: Ie57dbc0dd2842e771bb5fd9f69b8041aacaa005c
|
|
|
|
|
|
|
|
|
| |
Add am shell command to set and get idle
Add public API to check if an app is idle
Bug: 20534955
Bug: 20493806
Change-Id: Ib48b3fe847c71f05ef3905563f6e903cf060c498
|
|
|
|
|
|
|
| |
If it shouldn't be displayed for all users.
Bug: 13507605
Change-Id: I8fe8e5a98759c1ca058cc7d222817f6d580ffa11
|
|
|
|
|
|
|
|
|
|
|
| |
- Add new API to ask the activity manager what the current
importance of a particular package name is (along with a few
new useful importance levels).
- Fix my last alarm manager change to actually execute the
alarms we have now decided should run even while we are idle.
Change-Id: I1f14712b4e390770d53b185c96a1b36f6aadd687
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Issue #19912529: VI: VoiceInteractor callback ClassCastException
Fix to use correct argument.
Issue #19912636: VI: Documentation for VoiceInteractionSession.onBackPressed
Added documentation.
Issue #19912703: VI: VoiceInteractionSession NPE on Abort Request
Maybe fix this -- don't crash if there is no active session.
Issue #19953731: VI: Add value index to...
...android.app.VoiceInteractor.PickOptionRequest.Option
There is now an optional index integer that can be associated with
every Option object.
Issue #19912635: VI: Behavior of startActivity when in voice...
...interaction is unexpected
We now forcibly finish the current voice interaction task whenever
another activity takes focus from it.
Issue #20066569: Add API to request heap dumps
New ActivityManager API to set the pss limit to generate heap
dumps.
Also added app ops for assist receiving structure and screenshot
data, so that we can track when it does these things.
Change-Id: I688d4ff8f0bd0b8b9e3390a32375b4bb7875c1a1
|
|
|
|
| |
Change-Id: I00dfdef6a7ac61ab4ce16fefe1ddc5554ace0c88
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Not yet working, unless you turn off SELinux enforcing.
We need to update SElinux to allow the system process
to give apps access to /data/system/heapdump/javaheap.bin.
Currently watching can only be enabled through the shell,
such as:
adb shell am set-watch-heap com.android.systemui 1024
The last number is the process pss size in bytes, so this is
asking us to warn if it goes about 1K which will be all the
time.
Change-Id: I2089e5db2927afca0bf01a363c6247ee5dcb26e8
|
|
|
|
| |
Change-Id: I031443de83f93eb57a98863001826671b18f3b17
|
|
|
|
|
|
|
| |
Also fixed issue with ActivityStackSupervisor.moveTaskToStackLocked()
functionality not working correctly.
Change-Id: Ia13f1e92a7c59ce6543c226533ac8ea623488290
|
|
|
|
| |
Change-Id: Id3efb65a3f9cbf3c223ea08d51e2028180bd5479
|
|
|
|
| |
Change-Id: Idf3a364fc3826f6fe92f55b5c83b16b380d62ff4
|
|
|
|
|
| |
Bug: 19178148
Change-Id: I5819a71cdc48e0af4add11a6d4a503ec5cbe5d63
|
|
|
|
|
|
|
|
|
| |
When a stack is resized, make sure any non-fullscreen stack beneath it
becomes visible. This may mean additional activities are resumed in the
process.
Bug: 19083171
Change-Id: I5e7a3f82d76932ea2b9dbf0324ea183c42ee5496
|
|
|
|
|
|
|
|
| |
Creates a new, empty ActivityStack on a display. Use the binder call to
launch an activity on said stack.
Bug: 19001243
Change-Id: I0f04e8f2703bcc706f58e75333869fb35f6b1ee9
|
|
|
|
|
|
|
| |
Change the call to createVirtualActivityContainer to better describe what's
actually being created with the call.
Change-Id: Id3a32df19a5bb6740cbabcd65897349e9f2f2946
|
|
|
|
|
| |
Bug: 18479882
Change-Id: I0732e54838c4e04d9d727e7c5fd9d7e7bacbaa1f
|
|
|
|
|
|
| |
You now need to set a flag if you want this unsafe behavior.
Change-Id: I185e9a04e005e42a887c3d58a2818616790b060a
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Specifically, --ei (int extras) and --eia (int[] extras) now
use Integer.decode(), which means they accept negative
integers, base-16 integers formatted as #NNN and 0xNNN, and
base-8 integers formatted as 0NNN.
Additionally, --ez (boolean extras) can now be specified as
"true", "false", "t", "f", or an integer (any nonzero
treated as true). The previous behavior, based on
Boolean.valueOf(), would silently assign false if you
managed to get the spelling of "true" wrong.
Change-Id: I058254e907308006d403b5b7866c86bcaa03d8d3
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Add docs to Binder, Messenger, ResultReceier to explain their
relation (or lack there-of) to process lifecycle.
- Clarify some aspects of process lifecycle for services.
- Fix help text of am command.
- Fix per-package dumping of battery stats to not include history.
- Fix per-package dumping of proc stats to only include aggregated
and current stats and fix some formatting.
- Fix per-process dumping of meminfo to have an option to interpret
the input as a package, so including all processes that are
running code of that package.
- Fix top-level per-package debug output to correctly include all
of these improvements and give them a little more time (10s) to
complete for timing out.
Change-Id: I2a04c0f862bd47b08329443d722345a13ad9b6e2
|
|
|
|
|
| |
Bug: 15900074
Change-Id: I03b278f8e7a4618ea56a5f1935cfba34beb45981
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
...give time in some cases
This switch to multiple stacks broke the check to determine if it
should actually wait for a new activity to be shown. The new check
now also requires that the top activity be resumed, which means
we may get some false positives where we decide to wait and shouldn't,
but that is better than consistently not deciding to wait in some
cases when we should. (And we will always finish waiting then next
time something becomes visible).
Also add another time, which is how long it took from the startActivity
call to return with the result. And fix when we decide to report that
we are done so that, in the case where we are bringing an existing
activity to the foreground, we don't wait until its animation is complete.
Change-Id: Id38ca0070f04e7bf8c73e131fb055808553a0e2f
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Even though Shell user is allowed to perform cross-user actions,
lock that path down if the target user has restrictions imposed by
the profile owner device admin that prevents access via adb.
If the profile owner has imposed DISALLOW_DEBUGGING_FEATURES, don't
allow the shell user to make the following types of calls:
start activities, make service calls, access content providers,
send broadcasts, block/unblock packages, clear user data, etc.
Bug: 15086577
Change-Id: I9669fc165953076f786ed51cbc17d20d6fa995c3
|
|/
|
|
| |
Change-Id: Ic516e73d2e72ac0dc3136f7226cedd851fe22b85
|
|
|
|
|
|
|
| |
Also bundles all profiling options into a class.
Bug: 17040932
Change-Id: I85d675ee1494bdc7308caffdf94145d27c996e9d
|
|
|
|
|
|
|
|
|
|
|
| |
'adb shell am idle-maintenance' has traditionally been used to force
the system to consider itself to be in an "idle" state. Unfortunately
the new Job Manager hadn't yet been aware of this. Rectify the situation.
Also fixes a bug in debug logging that would cause a system server
crash under certain race circumstances.
Change-Id: I8a29bd7757924f8e464865235c344233fc03d8c3
|
|
|
|
|
|
|
|
| |
There is a list of supported ABIs in android.os.Build which
is ordered by preference. This is a more flexible list to use
instead of 2 fixed ABIs.
Change-Id: I6aa3b39b5ffa888ed83a870b937e18328dd6de39
|
|
|
|
| |
Change-Id: I7172a3a150fd83e2382ca3e4e4a0188758189f14
|
|\
| |
| |
| |
| |
| |
| | |
instrumentation."
* commit 'f7871c31469c6245c1b232a15104704f7481103c':
Support an ABI flag for instrumentation.
|
| |\
| | |
| | |
| | |
| | | |
* commit 'b9b31f4b8eda123e7b544d1a0fa886576064adca':
Support an ABI flag for instrumentation.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Allows us to choose what ABI a process uses when
launching it with "adb shell am instrument", for eg.
adb shell am instrument --abi arm64-v8a component/runner
Note that we only perform very basic validation of the
ABI. In general, there is no guarantee that the app will
launch with the instruction set we choose, for eg. if it
has native libraries that are for a different ABI.
bug: 14453227
Change-Id: Ifb7e89b53675080dc87941091ee5ac360f218d7f
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This gives a basic working implementation of a persist
running service that can start a voice interaction when
it wants, with the target activity(s) able to go through
the protocol to interact with it. It may even work when
the screen is off by putting the activity manager in the
correct state to act like the screen is on.
Includes a sample app that is a voice interation service
and also has an activity it can launch.
Now that I have this initial implementation, I think I
want to rework some aspects of the API.
Change-Id: I7646d0af8fb4ac768c63a18fe3de43f8091f60e9
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Define new FLAG_GRANT_PREFIX_URI_PERMISSION which indicates that a
Uri permission grant should also apply to any other Uris that have
matching scheme, authority, and path segments. For example, a prefix
grant for /foo/ would allow /foo/bar/ but not /foo2/.
Allow persistable and prefix grants to be issued directly through
grantUriPermission(). Relaxing persistable is fine, since it still
requires the receiver to actively take the permission.
Since exact- and prefix-match grants for the same Uri can coexist,
we track them separately using a new UriGrant key. (Consider the
case where an app separately extends READ|PREFIX and WRITE for
the same Uri: we can't let that become READ|WRITE|PREFIX.)
Fix revoke to always take away persisted permissions. Move prefix
matching logic to Uri and add tests. Add new flags to "am" tool, and
various internal uses around Intent and Context. Switch some lagging
users to ArraySet.
Bug: 10607375
Change-Id: Ia8ce2b88421ff9f2fe5a979a27a026fc445d46f1
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When in lock task mode only the specified task may run. All
attempts to switch to another task are ignored until the task
finishes or a call to stopLockTaskMode() is made.
Change-Id: I6cfe92fe1bcf22cd47b5398c08e23c52a4092dda
|
|/ /
| |
| |
| |
| |
| |
| |
| | |
Adds support for setting an array string extra on an intent when
launching an activity/service. Allows inclusion of commas using
an escape character.
Change-Id: I8857f7d28d60b75ddc65dc47f345a77230d00467
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- Abandon ActivityContainer.startActivity() in favor of
IActivityManager.startActivityAsUserInContainer().
- Modify Am to test starting an activity on a container.
- Create a DisplayContext as the base context if the activity token
is on a different display.
- Test for home display in more cases when manipulating home stack.
- Rename mDisplayInfos => mActivityDisplays.
- Create new method for moving task to front of stack regardless of
which display it is on.
Change-Id: I4fcb83ae844c5839ee3e2722229623d1a80ed921
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- Introduce concept of ActivityStacks residing on Displays and able
to be decoupled and moved around.
- Add a new interface, IActivityContainer for clients to handle
ActivityStacks.
- Abandon ordering of stacks based on mStackState and instead use
ActivityDisplayInfo.stacks<ActivityStack> ordering.
Progress towards closing bug 12078972.
Change-Id: I7785b61c26dc17f432a4803eebee07c7415fcc1f
|
|/
|
|
|
|
|
|
| |
StackBox is too constraining. Adding size and position to TaskStacks
directly makes stack positioning and management more flexible and
prepares for ActivityView.
Change-Id: I33c6b4e1c23a5a8069fd507c160bcb34e4d287b2
|
|
|
|
|
| |
Bug: 11690520
Change-Id: I84b10a6eb6e6404212ab9737e7cee1f1ad4d5309
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We now have the activity manager kill long-running processes
during idle maintanence.
This involved adding some more information to the activity manager
about the current memory state, so that it could know if it really
should bother killing anything. While doing this, I also improved
how we determine when memory is getting low by better ignoring cases
where processes are going away for other reasons (such as now idle
maintenance). We now won't raise our memory state if either a process
is going away because we wanted it gone for another reason or the
total number of processes is not decreasing.
The idle maintanence killing also uses new per-process information
about whether the process has ever gone into the cached state since
the last idle maintenance, and the initial pss and current pss size
over its run time.
Change-Id: Iceaa7ffb2ad2015c33a64133a72a272b56dbad53
|