To support runs that require different versions of an application
the discovery/installation process should be performed at the beginning
of each iteration and therefore has been moved into setup.
In order to be able to pass the package name of the app under test to
the instrumented test, the generation of the uiautomator commands needed
to be postponed until after the apk resolution had been performed.
The starting activity is not always listed in an apk or required to start
an application to its default state, for example youtube. Therefore now the
starting activity will only be used if one is available.
In order to pass arguments to the instrumented test via the command line
they need to be encoded, this commit utilises a ParamDict to ensure
parameters are encoded correctly before passing them as arguments.
When both global and config sections are present in an agenda, they both
will be processed by the ConfigManager. In each case, the path to the
agenda file was specified as the source, which resulted ConfigManager
complaining that the same source is being added twice. To avoid that,
the source is now suffixed with the section name.
Add to/from_pod implementations to level, so that it may be serialized
properly. In order to make sure that serialization is a reversible
operation, ensure that the level value is numeric.
Before performing feature discovery on a device, all cores are attempted to be
onlined, however due to power management on some phones, cores can be immediately
hotplugged out again therefore causing the command to file. This commit now just
logs a message to warn that the online process failed and the information obtained
from a device may be incomplete.
Previously if one of the runtime parameters failed to initialize it would cause
the the entire setup process to fail. Now if an error is encountered e.g. a core
went offline when trying to read its information, that particular parameter will
be disabled along with it's supported parameters. This means that only if a user
attempts to use the RT parameter will execution be stopped however it will raise
a potentially misleading unsupported parameter error.
This commit removes the UI elements from ApkUIWorkload to provide a base
ApkWorkload class in order to support workloads that do not require a GUI.
It also remove the `@once` decorator as apk resolution may need to be
run more than once per run.
Previously apk resolution would fail if the application apk was not present on
device as this was used to retrieve information e.g. the package name. To work
around this, the resolution process now supports searching the device for either
a list of package names retrieved from the workload or as a parameter passed by
the user at runtime and if found on the device will be pulled to the host to
perform its analysis.
As uiautomator2 uses apk for instrumented tests this allows for distinguishing
between a normal application apk and a uiauto test apk based on the apks package
name.
The new method of using uiautomation 2 is by using instrumented apk files rather
than JAR files. This commit updates the base workload has been updated to
install/uninstall the new uiautomation APK files and to invoke the relevant
instrumentation.
This re-adds the parser for the trace-cmd text trace, after it got
dropped along with wlauto sub-tree. There are minor differences from the
old WA2 parser.
- Changed to work with devlib start/stop markers
- TraceCmdTrace renamed to TraceCmdParser
- The file path is now passed to the parse() method rather than
on creation.
- detect whether markers are present in the trace and do not filter
if they aren't
In the case where the device screen was off prior to the execution of
the workload, but the user did not set screen_off, the screen will be
turned on during the setup. Previously, it would remain on for the
subsequent execution, however the correct behavior is for the workload
to always restore the screen to its previous state.
Tests now reside in the root of the repo, rather than in wa package.
This means they will no longer packaged and installed in user
deployments (they're only useful for developers).
WA2 Extensions had two features that have proven more trouble then they
are worth, and so they were removed from WA3 Plugins:
- Virtual methods (methods that automatically invoked super's version
without having to explicitly do that).
- It used to be possible to use strings or tuples to specify parameters
for extensions, and those were automatically "promoted" to Parameter
instances by the metaclass. This feature was never actually used.
This commit cleans up residual code for these features from Plugin
implementations and removes tests that used to exercise them.
- correct the import for merge_config_values fuction
- fixed expected result for set-with-list case; sequence merge will
produce unique values.
- check that the merge result type matches the other's type
Removing old and unsused files:
- wa/framework/old_output.py: superseded by output.py in the same dir
- the entire wlauto tree: replaced by wa/ tree; it's stale by now
anyway.
- log.py and actor.py from framework/ as neither is used.
assistant_params are now handled consistently with the other kinds of
params in TargetDescription, and they are now part of the default config
generated.
Updated the record command to allow revent recordings to be made.
They can be performed in 3 ways; the default is a standard recording
as in WA2, it can start a specified package before starting the
recording or a workload can be specified which launches the workload
and prompts the user to record each stage, naming and storing the recordings
appropriately.
Added a new ReventWorkload as a base for revent based workloads.
Updated ReventGui to use `revent_recorder` and now uses `target.model`
instead of `taget.name`.
Previously if a parameter was not specified via config it would not
be used during initialisation even if the parameter had a default
value. Now any parameters with default values are populated as necessary.
Revent files are automatically placed in the sub folder `revent_files` in the
workload directory when recording, therefore when trying to retrieve recordings
the getter now looks inside of the sub directory.
Previously trying to use the `__base_filepath` import from inside the `Package`
class, resulted in the error "`_Package__base_filepath` is not defined."
Added a workload type to handle workloads that have both an APK with an
application and associated automation JAR. Added benchmarkpi
implementation using using the new workload.
- get_by_extension was comparing the expected extension to the entire
tuple returned by os.path.splitext(), rather than just the extension
part.
- UserDirectory getter was looking in the root dependencies directory,
rather than the subdirectory for the owner.
- Filer getter was not handling non-existing paths properly.
- Workload's update_result stage has now been broken up into two parts:
extract_results and update_output. This is to allow the assistant to
pull output from the target in between the two stages.
- Updated assistant implementations for Linux and Android targets from
the exisiting code.
- Extended target descriptor code to handle assistants and their
parameters as well.
- Updated the target manager to actually make use of the assistants.
Previously a config point would try to validate the name attribute of the object
it was meant to be setting, rather than what it was meant to be setting it to.
- Implemented result processor infrastructured
- Corrected some status tracking issues (differed between states
and output).
- Added "csv" and "status" result processors (these will be the default
enabled).
- Fixed up some of the signal map for instrumentation
- Changed how priorites are specified -- no longer method name prefixes
but dedicated decorators, including an easy way of specifying a custom
priority level (no longer need to manually connect signals)
- Updated ExecutionTimeInstrument to work with the new system
- Also removed some dead code
"params" is interpreted differently in section vs workload entires in
the agenda; previously, this was handled in the generic entry
construciton function by examining the ID prefix of the entry to
distinguish between the two.
This is unreliable as the user may specify their own IDs that won't have
the expected prefixes. To handle this, the "params" alias resolution for
sections is now handled in section specific part of entry processing
(workloads are handled autmatically because that is the default for
the corresponding JobConfig config point).
Changing the way target descriptions work from a static mapping to
something that is dynamically generated and is extensible via plugins.
Also moving core target implementation stuff under "framework".
Changing the way target descriptions work from a static mapping to
something that is dynamically generated and is extensible via plugins.
Also moving core target implementation stuff under "framework".
