| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
| |
implement it.
Also clarify the behavior of the expand_template API in the presence of multiple-substitutions.
RELNOTES: None
PiperOrigin-RevId: 202719656
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a precursor to removing the DATA transition outright.
While we could also have changed the Mode.DATA instances to
Mode.TARGET (which would declare that we expect the attribute not
to apply any transition), that would break existing definitions and
make depot cleanup more delicate. Plus, these checks weren't being
consistently applied across attributes anyway so they don't really
offer much. A lot of this logic is really just leftover legacy
from the pre-dynamic configuration days.
PiperOrigin-RevId: 198085059
|
|
|
|
|
|
|
|
|
| |
Given a target (for example from a skylark aspect), one will be able to access a list of actions that the target generated using "target.actions". This is without additional memory footprint.
Actions themselves are not fully exposed to skylark (and thus there isn't much meaning to gather from them in skylark yet). Access methods will follow soon.
RELNOTES: None.
PiperOrigin-RevId: 188098079
|
|
|
|
|
|
|
|
|
|
|
| |
DeviceBrokerInfo to AndroidDeviceBrokerInfo.
Expose AndroidDeviceBrokerInfo and AndroidDex2OatInfo constructor to Skylark.
Mark both as undocumented, since this provider will we replaced with providers
implemented in Skylark once all rules are migrated.
RELNOTES: None
PiperOrigin-RevId: 186049807
|
|
|
|
|
|
|
| |
These can be part of the fixture targets.
RELNOTES: None.
PiperOrigin-RevId: 184943342
|
|
|
|
|
|
|
|
|
| |
This can be encapsulated in a device script fixture as an environment variable.
https://developer.android.com/studio/command-line/logcat.html#filteringOutput
RELNOTES: None.
PiperOrigin-RevId: 184683289
|
|
|
|
|
|
|
| |
android_instrumentation_test.test_app
RELNOTES: None
PiperOrigin-RevId: 184063294
|
|
|
|
|
|
|
|
|
| |
Do this by exposing DeviceBrokerInfo and a constructor for it in android_common.
See AndroidInstrumentationTestTest for an example.
RELNOTES: None
PiperOrigin-RevId: 183432674
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
android_instrumentation_test.args dictionary into the DeviceBroker in the stub template. Also remove extra %test_label% assignment
This allows users to pass arguments in the form of:
```
args = [
"--enable_display=false",
...
]
```
GITHUB: #903
RELNOTES: None.
PiperOrigin-RevId: 183089901
|
|
|
|
|
|
|
|
| |
android_instrumentation_test's runfiles.
GITHUB: #903
RELNOTES: None.
PiperOrigin-RevId: 182940009
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
android_instrumentation_test's runfiles, and pass the execpath of aapt_binary to the entry point using the --aapt flag.
This allows android_instrumentation_test to use the dynamically linked AAPT from the user-provided SDK.
The reason for not using %aapt% template expansion in the stub template is because @androidsdk//:aapt_binary is a shell script with hardcoded paths to the actual dependencies in its runfiles directory, but since this binary is called within an android_instrumentation_test's runfiles directory, the nested aapt runfiles directory doesn't exist because runfiles are not nested, but merged.
We can make this work by referring to the actual external/androidsdk/aapt_binary using a `../../` directory traversal, and we can also assume that the aapt_binary is there because android_instrumentation_test merged aapt's runfiles from the SDK.
RELNOTES: None.
PiperOrigin-RevId: 180888739
|
|
|
|
|
|
|
|
|
|
|
|
| |
instrumentation android_binary's AndroidManifest.xml references the correct package name of the instrumented android_binary.
During an instrumentation test, ART will use the targetPackage specified in the instrumentation APK's AndroidManifest to determine the application to be instrumented. We can perform this check in Bazel at execution time, before the apps are loaded onto the device.
See android_instrumentation_test_integration_test.sh for the e2e example.
GITHUB: https://github.com/bazelbuild/bazel/issues/903
RELNOTES: None.
PiperOrigin-RevId: 179564246
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 179425421
|
|
|
|
|
|
|
|
|
| |
instead of android_instrumentation.
GITHUB: #903
RELNOTES: None.
PiperOrigin-RevId: 173572553
|
|
|
|
|
|
|
|
|
| |
BazelJUnitRunner swallows argv, so we cannot pass args to the android test runner as flags.
Also, trim the trailing newline off of the name of the test suite class.
RELNOTES: None
PiperOrigin-RevId: 170354472
|
|
|
|
|
|
| |
This is a trivial change with a large file footprint.
PiperOrigin-RevId: 169169864
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 166368143
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 165910455
|
|
|
|
|
|
|
|
| |
These are depended upon by analysis code, so need to live in the same library
as lib.analysis. Moving them here makes it possible to split the build-base
library into separate libraries for analysis, execution, and rules.
PiperOrigin-RevId: 164847161
|
|
|
|
|
|
|
| |
This is part of splitting up the build-base library into separate libraries for
analysis, exec, and rules.
PiperOrigin-RevId: 164446955
|
|
|
|
|
|
|
| |
Also fix the remaining violations.
RELNOTES: None.
PiperOrigin-RevId: 163391215
|
|
|
|
|
|
|
|
|
|
|
|
| |
(Almost) all native declared providers are accessed as such and not as
native non-declared providers (inheritors of TransitiveInfoCollaction).
There are still three providers that use
TransitiveInfoCollection.WithLegacySkylarkName mechanism, I'll address
them in the follow-up CL.
RELNOTES: None.
PiperOrigin-RevId: 161655315
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 161395570
|
|
|
|
|
|
|
| |
With a few manual fixes for readability.
RELNOTES: None.
PiperOrigin-RevId: 160582556
|
|
This rule works with the android_instrumentation, android_device_script_fixture and android_host_service_fixture rules to support testing Android applications.
None of these rules are installed yet, because the forthcoming Android test runner is not yet open sourced.
https://github.com/bazelbuild/bazel/issues/903.
RELNOTES: None
PiperOrigin-RevId: 160465920
|