Move cleanup_assets from Workload up into TargetedPlugin. This way,
Instruments may also utilize it if they deploy assets.
More generally, it makes sense for it to be inside TargetedPlugin, as
any plugin that interacts with the target may conceivably need to clean
up.
Previously, when pulling an apk from the target to the host, the default
package name was used for both regular apks and test apks. This could
result in one overwriting the other. To prevent this ensure
`TestPackages` have the "test_" prefixed to their filename.
As part of our continous integration system it has become
clear that gathering the app package data as well as the
version name can provide useful.
Adding this functionality to mainline as it could prove
useful to other developers.
Ensure that the appropriate error message is returned to the user to
outline what caused the version matching to fail.
Additionally fix the case where if specifying a package name directly
the version matching result would be ignored.
`ApkRevent` workloads should be able to use the same Apk selection
criteria as `ApkWorkloads` therefore rely on the superclass to
instantiate the `PackageHandler`.
In additional to being able to specify whether the APK should be
uninstalled as part of a `APKWorkload`s teardown add the `uninstall`
parameter to the base `workload` class in order to specify whether any
binaries installed for a workload should be uninstalled again.
Add support for Android applications that are invoked through `am
instrument` (as opposed to `am start`) _i.e._ that have been
instrumented. See AOSP `/platform_testing/tests/` for examples of such
applications.
If the activity field of an instance of ApkWorkload does not the '.'
character, it is assumed that it is in the Java namespace of the
application. This is similar to how activities can be referred to with
relative paths:
com.domain.app/.activity
instead of
com.domain.app/com.domain.app.activity
Allow for specifying a list of supported APK versions for a workload. If
a specific version is no specified then attempt to a resolve any valid
version for the workload.
If a workloads `version` attribute is not set, and an APK file is
found, use this as the version number. This allows for workloads to not
specify a default version via parameters and for an available APK to be
automatically chosen.
Allow for easy configuring of a view for a particular workload as this
can vary depending on the device which can be used when using certain
instruments for example `fps`.
- Add copyright headers to files that did not already have them
- Update the year to the last year the file was modified in files with
existing headers.
Remove unused ``platform`` attributes and add ``supported_platforms``
along with check so that workloads can fail early when attempting to run
on an incorrect platform.
As part of resolving a resource, record its MD5 hash in the output
metadata. In order to enable this, resource resolution is now done via
the context, rather than directly via the ResourceResolver (in order not
to introduce a context dependency in the Gui object, context now
emulates the resolver interface).
We only need to deploy the gui once, therefore move the `deploy` method
call into `initialize` the corresponding `remove` method is already in
`finalize`.
The `install_timeout` variable is used to allow extra time when
installing an apk, if the apk is not present on the host system it
will be pulled back to the host, therefore we should allow extra time
when transferring the file in the other direction as well.
Now allows a `prefer_host_package` parameter to be set to control
whether a package located on the host system (`True`) or on the target
(`False`) should be favoured during resolution.
`pull_apk` now returns the path to the apk it pulled from the device so
WA can keep track of it and avoid conflicts with other apks present
on the host.
Fix an issue where AndroidWorkload.pull_apk would sometimes get the
wrong package if the desired package name is a substring of another
package name. Rather than using a regex to match the package name, use
the new get_package_info method to match the name exactly.
Fix an issue introduced by commit 42fb3eb
framework/workload: make "no matching package" message more useful
PackageHandler was incorrectly passing self.name into the error message
instead of self.owner.name.
Make the error message reported when no matching Android app package
could be found more useful by including the workload name, and, if
applicable, sought version.
On some devices an installed apk filepath can contain an '=' character
which was previously used to end the regex match. Now match with the
package name as well to ensure the file path is extracted correctly.
To reflect that the current implementation of ReventWorkload uses an APK
file on the device the name has been changed appropriately and the
relevant workloads have been updated.
