To speed up the test. For a trivial am instrument run:
[Before]
0m01.53s real 0m00.16s user 0m00.16s system
[After]
0m00.72s real 0m00.21s user 0m00.11s system
Bug: 204195830
Test: am instrument -w
Change-Id: I66196d1db9169681dabb2e5dacdd18e6105ad75a
Issure:
When no args to run am.jar,mAm is not initialized before use
process will crash in NRE
Solution:
Initialize mAm in constructor
Bug: 202471754
Test: manual
Running follow sh on the device displays help messages correctly
base=/system
export CLASSPATH=$base/framework/am.jar
exec app_process $base/bin com.android.commands.am.Am
Change-Id: I088f4f5b4072d350c217655a291658d0bfd506e9
Since introduction of ALLOW_TEST_API_ACCESS, it is now possible to
grant access to test apis for the whole UID, instead of just a starting
process.
This resolves the issue, where a forked test process cannot access @TestApi's.
Bug: 147113465
Test: atest CameraEvictionTest#testBasicCamera2ActivityEviction
Change-Id: I8dd3bbacdb263a3e30539f43d8081f6d78e80155
Bug: 174932174
Test: I solemnly swear I tested this conflict resolution.
Exempt-From-Owner-Approval: refactoring with team leads buy-in
Change-Id: I9262a08ffc1ccede8e519d0eed90ed2bfcf0232c
As general background, OWNERS files expedite code reviews by helping
code authors quickly find relevant reviewers, and they also ensure
that stakeholders are involved in code changes in their areas.
Some teams under frameworks/base/ have been using OWNERS files
successfully for many years, and we're ready to expand them to cover
more areas. Here's the historical coverage statistics for the last
two years of changes before these new OWNERS changes land:
-- 56% of changes are fully covered by OWNERS
-- 17% of changes are partially covered by OWNERS
-- 25% of changes have no OWNERS coverage
Working closely with team leads, we've now identified clear OWNERS on
a per-package basis, and we're using "include" directives whenever
possible to to simplify future maintenance. With this extensive
effort, we've now improved our coverage as follows:
-- 98% of changes are fully covered by OWNERS
-- 1% of changes are partially covered by OWNERS
-- 1% of changes have no OWNERS coverage
This specific change is automatically generated by a script that
identifies relevant "include" directives.
Bug: 174932174
Test: manual
Exempt-From-Owner-Approval: refactoring with team leads buy-in
Merged-In: I3480ddf2fe7ba3dfb922b459d4da01fa17a2c813
Change-Id: I3480ddf2fe7ba3dfb922b459d4da01fa17a2c813
This makes two changes to enable the instrumentation of system server
and other system processes:
- A new option '--no-restart' has been added to 'am instrument', that
causes the test apk to be loaded without restarting the target app.
- On debuggable devices, the check that the test apk has the same
signature as the target app is not performed.
With these changes, a test apk with instrumentation configured
with targetPackage="android" can run a test from within the system
server process, on debuggable devices. These options may also allow
other system processes to be tested.
See go/internal-api-testing for more information.
Test: atest FrameworksInProcessTests
Change-Id: I8829bcbe7f3373170bcf1e7fa869d5d31f40576d
This provides a signal for MediaProvider to whitelist access for full
external storage access.
Here is an overview of how the flow looks like:
1. When app is started within instrumentation with --no-isolated-storage
flag, ActivityManagerService will grant OP_NO_ISOLATED_STORAGE to that
package.
2. MediaProvider will note the OP_NO_ISOLATED_STORAGE app op as fallback
in case app doesn't have MANAGE_EXTERNAL_STORAGE permissions.
3. When instrumentation finishes, ActivityManagerService will change
mode of OP_NO_ISOLATED_STORAGE app op to MODE_ERRORED.
Test: atest ExternalStorageHostTest
Bug: 149894531
Change-Id: I51cd87e5e887b887fd8ac7a1a7ffff208266ffa8
There are more runners than those updated in tradefed/testtype/, which donot/cannot push --no-test-api-checks arg to `am instrument`. Instead reverse the default, so that by default `am instrument` disables test api enforcement policy.
Test: atest CtsHiddenApiBlacklistApi27TestCases \
CtsHiddenApiBlacklistApi28TestCases \
CtsHiddenApiBlacklistCurrentApiTestCases \
CtsHiddenApiBlacklistDebugClassTestCases \
CtsHiddenApiBlacklistTestApiTestCases \
CtsAppSecurityHostTestCases:android.appsecurity.cts.ExternalStorageHostTest#testMediaEscalation \
CtsAppSecurityHostTestCases:android.appsecurity.cts.StorageHostTest#testVerify \
CtsAppSecurityHostTestCases:android.appsecurity.cts.DirectBootHostTest#testDirectBootNative
Exempt-From-Owner-Approval: small fix
Bug: 133832325
Change-Id: Id1870cdd4bb0a51bddede24afd7f87d6e5ec766c
By default instrumented processed have access to @TestApis; however for certain CTS tests we want to disable access to test APIs, where this flag would be used.
Test: manual
Bug: 133832325
Change-Id: Id56ce3079bcea2632d4002edcf120d9d5c9e0a26
Merged-In: Id56ce3079bcea2632d4002edcf120d9d5c9e0a26
See build/soong/README.md for more information.
Also converts the rest of frameworks/base/tools/streaming_proto.
Bug: 122332340
Test: m checkbuild
Change-Id: I87c500c5464fb1722b4b518d89065f5e1ee29a97
(cherry picked from commit 45c0d71e774c84ec81392393a0fafad398d2838d)
Also makes bit print that logcat, if available, instead of just the
stack trace.
This means that when you run a test you don't also have to run logcat in
some other window, and then scroll around forever looking for the one
test in question.
Test: bit -t GtsIncidentManagerTestCases:com.google.android.incident.gts.IncidentManagerTests\#testFail
Test: bit -t GtsIncidentManagerTestCases:com.google.android.incident.gts.IncidentManagerTests\#testDoesntExist
Bug: 129875642
Change-Id: I8940ff379c919482f4a545cb90d25bdbaa2b4f15
When starting a process under instrumentation using this new
"--no-isolated-storage" flag, the process would be able to see the
full external storage.
Bug: 117229024
Test: adb shell am instrument --no-isolated-storage \
-e class android.media.cts.EncodeDecodeTest#testEncodeDecodeVideoFromBufferToBuffer720p \
-w android.media.cts/android.test.InstrumentationTestRunner
Change-Id: I7973b123cf4fc08e8ce2b05bd4c23fa41b1cdcdf
Some tests need to use hidden APIs to check the internal state of
the framework. For those special use cases, we add a new flag to
ActivityManagerService.startInstrumentation that enables to start
instrumented processes without hidden API enforcement. Individual
test harnesses can change their Am command to request the exemption.
Bug: 64382372
Test: adb shell am instrument --no-hidden-api-checks <component>
adb logcat | grep 'Accessing hidden'
Change-Id: I1d734a95423fae90dae63ff09d5f606495830905
Add instrumentation data proto to host proto lib and add a few comment
to am instrument.
Test: no test needed
Change-Id: Ibbb0394dcf0ad27b53d5c97104456798863ce82c
Add an option -f to record instrumentdata proto produced by am instrument
to a file in addition to printing to stdout. Default path is
/sdcard/instrument-logs/log-yyyyMMdd-hhmmss-SSS.instrumentation_data_proto.
If the file exits, it will be deleted before writing. Path can be changed
via optional <FILE> argument after -f.
If -f and -m are both present, proto will be written to a file and print
to stdout.
Test: build, flash and run:
bit -bi FrameworksCoreTests
adb shell am instrument -w -r -f tmp/tmp.log \
-e class com.android.internal.os.BatteryStatsNoteTest \
com.android.frameworks.coretests/android.support.test.runner.AndroidJUnitRunner
Change-Id: Iabc320c066d5995eee842c26416623eeb3d403f4
We can use the new mechanism to ask the calling shell to open
a file in order to implement the rest of these commands, allowing
you to give the path to an apk to install. That API is thus
extended to allow you to open readable files, not just opening
file for writing.
Doing this however means we no longer can pass a file path to
AssetManager for the apk to parse, we only have an already open
fd for that. Extending AssetManager to allow adding apks from
fds is not that hard, however, since the underlying zip library
already supports this.
This main thing this changes is in AssetManager.cpp where we
retrieve the open zip file for a particular apk that has been
added. This used to look up the zip file by path every time
it was needed, but that won't work anymore now that we can have
things added by fd. Instead, we keep track of each opened zip
in the AssetManager, so we can just directly retrieve it from
the asset_path representing the item that was added. As a
side-effect, this means for normal paths we no longer need to
look up by name, but just have the opened zip file directly
accessible. (This is probably good, but it does mean that we
no longer run the logic of seeing if the zip file's timestamp
has changed and re-opening it if it has. We probably shouldn't
be relying on that for an active AssetManager anyway, and maybe
it is even good that we don't allow the zip file to change
under it?)
A follow-up change will finally remove the Pm.java implementation
and turn the pm "command" into a simple shell script that runs
cmd package.
Test: manual
Change-Id: Ie103e3bdaa5b706796cc329254f2638151a3924f
Bit used to only see success results and failures (== assertion failures?),
and didn't see "errors" (other exceptions) and test process crashes.
Fixed it.
Now it also returns an error status code if there was a test failure.
Bug 64292779
Test: manual
Change-Id: Iaba93910d32abfc615ae595746a0e9be1108583a
This hidden functionality is no longer support/needed since
we now have multi-window/display. A new view group class
will be added later that uses multi-window to support remaining
functionality of this class.
Test: go/wm-smoke
Change-Id: Ie2fa2de92841d33199da9988741905060dd1ddf4
Previously the output from perftests was printed in a random order:
INSTRUMENTATION_STATUS: timeGetDataCapacity_standardDeviation=5
INSTRUMENTATION_STATUS: timeGetDataCapacity_median=486
INSTRUMENTATION_STATUS: timeGetDataCapacity_mean=489
INSTRUMENTATION_STATUS: timeGetDataCapacity_min=484
INSTRUMENTATION_STATUS_CODE: -1
Now it's always printed in the same (sorted) order.
INSTRUMENTATION_STATUS: timeGetDataCapacity_mean=489
INSTRUMENTATION_STATUS: timeGetDataCapacity_median=486
INSTRUMENTATION_STATUS: timeGetDataCapacity_min=484
INSTRUMENTATION_STATUS: timeGetDataCapacity_standardDeviation=5
INSTRUMENTATION_STATUS_CODE: -1
Test: manual test
Change-Id: I807aa05e6523b70a132ab97fc099156bb3dc1f96
There is a flag for 'adb shell am instrument' that disables animations, which
is useful for testing (if you want to, for example, disable animations to speed
up tests or remove animation-caused side-effects as a factor). But only the
pre-honeycomb animations (window transitions and window animations) were listening
to this flag. This change makes animators listen as well, so all three duration scale
settings are affected.
Bug: 32072407 --no_window_animation ADB arg should set all animation scales to 0.0f
Test: manual. Ran frameworks APCT tests with --no_window_animation and verified
that all three types of animations had their duration scales set to 0 for the
duration of the tests.
Change-Id: I5ae4a60faa714c9534dfae58d1efcd54f577d82b
For almost everything... except instrument, which still needs
to be run as the shell user so its UiAutomator callbacks
will work correctly (and not create security holes).
Test: manual
Change-Id: I2e62714a2d5b52501aa261b7e4d6b282b54a0027
Refactor the am instrument command and add a version that
outputs protobuf in addition to the old one that prints
loosely formatted text.
Change-Id: I34079d8af2b7b6c6c59837d54719806109ba286c
Test: bit tool
...time it's called from dumpstate
Bring back the shell-side implementation of this, until we can
figure out why the raw shell command transaction is failing.
Test: bugreport works
Change-Id: Ia9422a653feffb0236613d43e022458c101b9583
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
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
It's a protected broadcast, so sending it directly from 'am' is
no longer an option. This is needed for CTS as well as being
generally useful during app development.
Bug 28406044
Change-Id: I101915a8c6f19454330a8db2079a75023c112582
Now that CE data isn't available until after a user is unlocked, we
need to delay the PRE_BOOT_COMPLETED broadcasts. This is done by
adding a new RUNNING_UNLOCKING user state to the UserController
lifecycle.
We now track the last fingerprint a user was logged in under, and we
dispatch PRE_BOOT receivers when that fingerprint changes. To work
around battery pull issues, we only persist the updated fingerprint
once all PRE_BOOT receivers have finished. This is less granular
than the original solution, but it's still correct. We only consider
a user as "logged in" once it transitions into the RUNNING_UNLOCKED
state.
When starting a process, track if the user was "unlocked" when
started, so that we only spin up unaware providers in processes
started before user unlock.
Add generic IProgressListener to communicate PRE_BOOT progress and
strings up to lock screen. For now, LockSettingsService just blocks
until finished, but it could display these strings in the future.
Bug: 27220885
Change-Id: I349439776b885acd32f6a578d8951ffd95640be2
Since the data returned by these calls can grow unbounded based on
various GET flags, we need to switch 'em over.
Bug: 27391893
Change-Id: Ie849ca30dbaaa91158da4c83675657715629a0ee
Use write only file descriptors for am commands. Having read-write
file descriptors isn't needed, and not all SELinux app domains have
read access to /data/local/tmp file descriptors.
Addresses the following denial:
avc: denied { read } for path="/data/local/tmp/foo" dev="dm-2"
ino=654084 scontext=u:r:system_app:s0
tcontext=u:object_r:shell_data_file:s0 tclass=file permissive=0
Steps to reproduce:
adb shell ps | grep settings
adb shell am dumpheap PID_FROM_ABOVE /data/local/tmp/settings.hat
Expected:
1) command works
Actual:
1) SELinux denial and no settings.hat output.
Bug: 27472701
Change-Id: Id8df0c5a41046b405444e14c70075c986d9936c3
...isUserAMonkey for testing purpose
Add an argument for the caller to specify if they are a poo flinging
monkey.
Change-Id: I0e149a8d78776abaf07517bd4ae886047b7f4252
Add the means to protect FBE keys with a combination of an auth token
from Gatekeeper, and a hash of the password. Both of these must be
passed to unlock_user_key. Keys are created unprotected, and
change_user_key changes the way they are protected.
Bug: 22950892
Change-Id: Ie13bc6f82059ce941b0e664a5b60355e52b45f30
Specifying the new flag will enable several features in the runtime
required by the native debugger to debug Java and C++ code at the same
time.
The enabled features:
* Force JIT (never use the interpreter)
* Debug info generation
* Disbale some optimizations
Change-Id: Iaf5ab649715a0c274bd1b0fc64e483705da53cd0
