v2.1.2

fixed misleading argument name for timeBasedTerminate

v2.1.1

new feature: added property to text insert exploration action to allow for automatically close keyboard after setting a input text
improvement: widget highlighting allows for stroke customization and now uses rounded rectangles for improved visibility

v2.1.0 included screen-size into device response data and modified Ab…

…stractModel.generateWidgets to be able to access this response data (ActionResult) directly

v2.0.0

Fixes for imgDirectory and initial watcher onContextCreate call

Refactoring Strategies & Selectors (EAP-version)

Refactoring of the previous design of Exploration-Strategies and Strategy-Selector to get rid of necessary base strategies like Back, Terminate etc. Basically all previously default 'selectors' were invoking some exploration action and are thus now inheriting from AExplorationStrategy instead.

Note: this is an eap version, it contains many deprecation annotations which can be used for easy migration before switching to the newer version of DM-2.

Changelog:

• all old classes and interfaces for strategies and selectors were replaced by
  IActionSelector parent interface used in the exploration loop to abstract away if the next action is determined by a selector or a strategy directly

  AExplorationStrategy all strategies should inherit from this class. Strategies are assumed to always have a next action, if this is not the case for yours you should overwrite hasNext(eContext): Boolean. By default the very first action of any exploration is going to be an app launch, if you want to differ from this behavior you have to overwrite nextAction(eContext):ExplorationAction
  A strategy has to implement the methods

  • getPriority() : Int // this value is ranked against all other strategies and selectors to decide who is going to deliver the next exploration action
  • computeNextAction(eContext) : ExplorationAction // the next action to be executed

  AStrategySelector can be used if you want to 'switch' between different strategies depending on the current exploration context (e.g. to implement some fallback to random).
  You have to implement the method selectStrategy(eContext):AExplorationStrategy. The returned strategy is used to determine the next action by calling its nextAction method.

• all previous default 'selectors' (now strategies) can be retrieved by accessing the respective function in the new object DefaultStrategies

• the Exploration-API was extended with some convenience function to directly pass lists of strategies and selectors, such that it is no longer mandatory to use a command builder. However when using these function, no default strategies or selectors are going to be used.

DM-2 v1.2 Major Changes and new Features

This version brings some major changes in the package structure and extracted UI properties, which were simply unavoidable for the new features (i.e. element visibility & keyboard identification).
The good news is the device interface and exploration model should be stable now and in particular the model is finally easily extendable again, the bad news is that previously stored models are not compatible with the new version and existing code bases will require some adaption like package path imports, class name fixes and adaptions to use the new UI properties.

requirements

• the new android gradle version will probably require you to install android build tools 28.03 or higher
• Even though DM-2 still supports Android 6.0 (API 23), we strongly recommend to use Android 7 or higher (API 24+) to completely benefit from the new features. This restriction comes from the underying UiAutomator as some of the API functions required for the new features (like input field hint texts) are only available since API 24.

If you experience build errors you may need to delete your gradle cache as gradle seams to have some trouble to fetch the right dependencies after version changes sometimes.

new features

• proper UI visibility detection by analyzation of overlying (even popup) windows and rendering order
  • the property visibleAreas can be used during exploration to determine which areas of an UI element are visible to the user
  • visibleBounds is the overall visible bounding box but may be partially overlapped by other elements, therefore visibleAreas should be used to determine action target coordinates
  • boundaries are the boundaries as defined in the UI hierarchy, these may be bigger than the visibleArea if the element is partially hidden or out of screen
• the isKeyboard property can be checked to identify (soft) keyboard elements
• an UI element now stores both its parent and child hashes, which allows for easy traversal in the hierarchy within a state
• we found the property hintText, which seams to contain the initial display text of input fields
• the id computation and widget/state generation functions can now easily be overwritten via inheritance, which allows for customization of the similarity metrics
• we now have Action-Queues which allow to send a sequence of actions wich is completely executed on device before a result state is retrieved. This can be e.g. useful to fill all available edit-fields before clicking anything, as state similarity still has some issues to recognize states as similar when for example a clear icon appears after filling an edit field.
• we have a new function navigateTo which allows to scroll to an element which is currently out of screen and interact with it
• you can configure the quality of screen-shots via configuration UiAutomatorServer.imgQuality and if images are allowed to be fetched asynchronously via UiAutomatorServer.delayedImgFetch which speeds up the exploration noticeable
• model parsing now offers the option to parse models parallel or sequential (mostly for debugging)
• critical performance and bug fixes in model parsing were applied

To allow for better modularity in exploration and analysis modules, the exploration model and device interface are now separate git submodules which can be easily included separately via jitpack (repository maven { url 'https://jitpack.io' }) with

compile "com.github.hotzkow:platformInterfaceLib:b48c1c48e3"
compile "com.github.hotzkow:explorationModel:8c6168d3f2"

In theory this allows to implement the device interface on arbitrary platforms like web or other mobile platforms and to reuse ones base analysis/exploration approach based on the generated exploration model.
We hope this simplifies the integration and reduces the effort to integrate new ideas and features.
We would be happy to integrate useful merge requests to improve our framework.

The gradle build of DM-2 will automatically use the jitpack repository if the git submodules are not initialized and use the local code otherwise.

1.1-SNAPSHOT

Among critical fixes for the model dump/load the state id (similarity) definition and the device action interface changed dramatically. This may require some adaption in custom strategy implementations.

For state/widget id's the images are no longer affecting the unique id but rather taken into account for the configuration id only to make the similarity more robust against animated content like color changing buttons/navigation elements.

A model parsing now offers the option to parse models parallel or sequential (mostly for debugging) and has supports a compatibility mode. This modus allows to transfer (old) previously dumped models to the newest implementation structure (e.g. if the order of properties changed). However this function is limited if not all properties, which are relevant for the id computation, were persisted in the older dump.

The action interface was refactored to remove the need to touch the device driver could to support new device actions. Instead we now have Action-Queues which allow to send a sequence of actions wich is completely executed on device before a result state is retrieved. This can be e.g. useful to fill all available edit-fields before clicking anything, as state similarity still has some issues to recognize states as similar when for example a clear icon appears after filling an edit field.
Moreover for the release it is planned to define most of the available device actions in the device interface such that the user can simply specify custom actions by using these in combination via action queues.

However, right now this new action queue feature breaks the 'onNewAction' method of model watcher, I.e. only the very first action is reported to the watcher. This is supposed to be fixed for the final release.

1.0

Version 1.0

Release for ASE'18

ACM DL Artifact can be found here

1.0-RC4

Release candidate 4.

• Bug fixes.
• Enhanced UI stabilization
• Fixed Android 6.0 support

DM-2 v1.0-RC3

New features:

• Visualization graph

Improvements:

• Performance and stability improvements on Automation Engine

Bug fixes

• Soot as a local dependency
• Improved app crash handling
• Logcat now is correctly stored