Introduce 'unlock_screen' option in order to help in automating Android
tests by unlocking device screen automatically. Surely this works only
if no passcode is set.
'unlock_screen' option implicitly requires turning on the screen. IOW,
it will override value of 'screen_on' option.
'diagonal', 'vertical' and 'horizontal' are valid values for
'unlock_screen' option as of now.
Note that this patch depends on
https://github.com/ARM-software/devlib/pull/659 in devlib repo.
Signed-off-by: Metin Kaya <metin.kaya@arm.com>
If the device does not have the hoptplug module installed, avoid
unnecessary querying of the device to check the number of cpus which
can cause issues with some devices.
Update our version of pylint to use the latest version and update the
codebase to comply with the majority of the updates.
For now disable the additional checks for `super-with-arguments`,
`useless-object-inheritance`, `raise-missing-from`, `no-else-raise`,
`no-else-break`, `no-else-continue` to be consistent with the existing
codebase.
- 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.
Previously incorrect method calls were used to try and convert 'max' and
'min' into their corresponding frequencies, now call the correct methods
and refactor the conversion into a separate method.
Allows setting of select android runtime configuration for devices running
chromeos and which support android. Currently only 'brightness' is functioning
correctly therefore the other parameters are only enable for standard android devices.
Previously when validating cpufreq runtime parameters it would check too
early whether the cpu was online, not allowing for the fact that the cpu
might be being onlined before the parameter was committed to the device.
Some targets need more than 5 seconds to re-connect to a wifi network
after disabling airplane mode. To fix that, poll for network up to 20
seconds and show a warning if unreachable.
The generic "frequency" runtime parameter was only being set when there
are common frequences between avialable cores. It should always be set,
even if there are no frequencies in common, as it still valid to use it
with special values "min" and "max", in which case it should resolve
correctly to the appropriate frequencies.
This enables you to do things like:
global:
runtime_parameters:
airplane_mode: true # This improves repeatability of energy measurements
workloads:
- name: foo
- name: bar
- name: geekbench
runtime_parameters:
airplane_mode: false # Geekbench requires network, and we don't care
# about energy for that workload anyway
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.
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".
