This is liable to change in the future.
android_instrumentation_apk() rule is used to generate an Android Instrumentation APK.
Android's Testing Fundamentals documentation includes a diagram that shows the relationship between an "application package" and a "test package" when running a test. This rule corresponds to a test package. Note that a test package has an interesting quirk where it is compiled against an application package, but must not include the resources or Java classes of the application package. Therefore, this class takes responsibility for making sure the appropriate bits are excluded. Failing to do so will generate mysterious runtime errors when running the test.
The name of the rule, as well as the name of the APK generated by this rule.
Relative path to the Android manifest for the APK. The common case is that the manifest will be in the same directory as the rule, in which case this will simply be
'AndroidManifest.xml', but it can also reference an
List of build targets whose corresponding compiled Java code, Android resources, and native libraries will be included in the APK. From the transitive closure of these dependencies, the outputs of rules of the following type will be included in the APK:
List of build target patterns that identify the build rules that can include this rule in its
ExamplesHere is an example of an
android_instrumentation_apk()rule that tests a
android_binary(), and depends on a test package.
android_library( name = 'test', srcs = glob(['test/**/*.java']), ) android_binary( name = 'messenger', manifest = 'AndroidManifest.xml', keystore = '//keystores:prod', package_type = 'release', proguard_config = 'proguard.cfg', deps = [ ... ], ) # Building this rule will produce a file named messenger_test.apk android_instrumentation_apk( name = 'messenger_test', manifest = 'AndroidInstrumentationManifest.xml', apk = ':messenger', deps = [ ':test', ], )