This new command is used to attach runtime agents to a running application:
attach-agent <PROCESS> <FILE>
Attach an agent to the specified <PROCESS>,
which may be either a process name or a PID.
Test: m test-art-host, manual testing:
. invalid syntax, missing arguments
. invalid syntax, extra arguments
. invalid numeric PID
. invalid process name
. valid process, not debuggable
. valid process, missing agent
. valid process, valid agent
Bug: 31682382
Change-Id: Ife88dbf23991dde7945d9208e54cd014bb7ecdc6
Internal version of UMS maintains a self-locking data-structure of user
states that is pushed from ActivityManager. Previously there could
be discrepancies between UMS.isUserUnlockingOrUnlocked and
UM.isUserUnlockingOrUnlocked, which is calling a blocking version
in ActivityManager.
Test: manual + UserManagerTests
Bug: 31995235
Bug: 31833240
Change-Id: Ibafe403f57cd32d9052bb55fe7273a861be1d037
Although currently not used, the parameter is expected to be in microseconds,
not milliseconds. Hopefully this will avoid issues if the time is used in the
future.
Test: ...make sure it builds locally
Change-Id: Ie131370d3e8c8105623fc60375054f4b22cec110
1. Modify DPM.isProvisioningAllowed to allow it to happen
2. Introduce hidden API createProfileForUserEvenWhenDisallowed for
ManagedProvisioning app to create profile under DO.
Apps with MANAGE_USERS permission can clear the
DISALLOW_ADD_USER restriction anyway, so they do not gain extra power.
Test: runtest -x frameworks/base/services/tests/servicestests/src/com/android/server/pm/UserManagerTest.java
Test: cts-tradefed run cts --module DevicePolicyManager --test com.android.cts.devicepolicy.CustomDeviceOwnerTest#testIsProvisioningAllowed
Bug: 31895999
Change-Id: I10dc3043653130ae717a1d3d8256c9e73231bb21
The only thing not removed is the "instrument" command, which
really needs to run Java code in the shell. We'll deal with
that later.
Test: manual
Change-Id: I9df0cdf831ac280cb0eb85c857d27166bc00604d
If we created a BROWSE PendingIntent early during boot (while the
device was still locked), we would resolve the MIME type as "null"
meaning the intent would fail to launch.
Since we always know what the MIME type will be, set it explicitly.
Test: boot device while USB device attached
Bug: 30742481
Change-Id: I23c523cbe2660ca63a3b7df1f41300ab803b314c
There is no functional change. This is to support adding new types of zygotes
that all operate using the same protocol.
Bug: 21643067
(cherry picked from commit 94e824bc1b)
(cherry picked from commit 96b49848e7)
Change-Id: I2e12057e4c2e7567f909d699b487e70b1664cca8
This adds a new init-spawned daemon, webview_zygote, that starts a JVM and
acts as a zygote process for WebView isolated_app services.
Test: m
Test: angler boots
Test: Turn on Settings>Developer>Multiprocess Webview. webview_zygote32 or
webview_zygote64 start (requires dependent CLs).
Bug: 21643067
Change-Id: Ida98bd04b4d77736b672b03af651c4eb97ce88c1
We call uncrypt services to setup / clear bootloader control block (BCB)
for scheduling tasks under recovery (applying OTAs, performing FDR).
However, we cannot start multiple requests simultaneously. Because they
all use the same socket (/dev/socket/uncrypt) for communication and init
deletes the socket on service exits.
This CL fixes the issue by a) adding synchronized blocks for the service
requests; b) checking the availability of the socket before initiating a
new one.
Note that adding synchronized blocks to RecoverySystem doesn't help,
because the calls could be made from different processes (e.g. priv-app,
system_server).
Bug: 31526152
Test: FDR works while a priv-app keeps calling clear BCB.
Change-Id: I95308989e849a9c98a9503ac509f2bc51ed3de19
(cherry picked from commit 794c8b0b3f)
We call uncrypt services to setup / clear bootloader control block (BCB)
for scheduling tasks under recovery (applying OTAs, performing FDR).
However, we cannot start multiple requests simultaneously. Because they
all use the same socket (/dev/socket/uncrypt) for communication and init
deletes the socket on service exits.
This CL fixes the issue by a) adding synchronized blocks for the service
requests; b) checking the availability of the socket before initiating a
new one.
Note that adding synchronized blocks to RecoverySystem doesn't help,
because the calls could be made from different processes (e.g. priv-app,
system_server).
Bug: 31526152
Test: FDR works while a priv-app keeps calling clear BCB.
Change-Id: I95308989e849a9c98a9503ac509f2bc51ed3de19
This introduces a new feature of the IBinder command protocol
to allow the shell command implementation to call back into
its caller to ask it to open files in the calling context. This
is needed so that commands that have arguments specifying files
can open those files as the calling shell, not the system (or
whatever) process.
To test this all out, move the "am start" implementation over
to ActivityManagerShellCommand, in particular along with its
option to specify a file in which to write profiling data.
Test: Manual
Change-Id: I0c1e3857defefbd19a2ac29413aafbb34b1e48a3
This will enable the developers to check if they could replace an unbuffered
I/O operation with a corresponding buffered I/O operation.
The policy can be set as follow:
StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder()
.detectUnbufferedIO().build());
Test: vogar BlockGuardTest
Bug: 3018772
Change-Id: Ib804a8e9980ae40abfd216f8b87c250fd413bd5c
(cherry picked from commit 9b7184a8fd)w
