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
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
The new option "--track-allocation" is to work with the new
allocation tracker in ART.
Bug:20037135
Change-Id: Ic5f8945ab4c1f167c27b05ad0d11d04bac680c1f
Add the ability to am to be able to track binder transact calls. This
will help us diagnose excessive IPC calls.
This CL adds the trace-ip command to am. The usage is,
To start binder transaction tracking,
am trace-ipc start
To stop tracking and dump the data to a file,
am trace-ipc stop --dump-file <FILE>
Bug: 21398706
Change-Id: Ic0c9b3be757dd0662a2750a0d8447e2a5ef1fa90
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
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
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
- 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
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
Also fixed issue with ActivityStackSupervisor.moveTaskToStackLocked()
functionality not working correctly.
Change-Id: Ia13f1e92a7c59ce6543c226533ac8ea623488290
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
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
...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
