chchgb/android-crawler

Automatically exported from code.google.com/p/android-crawler

android-crawler's Issues

Toggle Button Support

Toggle Button is seen as a event (simple type = button) while it's supposed to 
be an input.

This is probably a regression due to the removal of filters.

Original issue reported on code.google.com by nofatclips on 12 Nov 2011 at 11:38

Menu navigation

Support for opening menu and selecting the options is missing.

Original issue reported on code.google.com by nofatclips on 25 Oct 2011 at 6:30

Input on widgets without ID

At the moment, events are optionally fired on widgets without id: in order to 
identify the correct the widget, its index and its name are used.

The same should happen with inputs.

Original issue reported on code.google.com by nofatclips on 6 Nov 2011 at 9:02

Hierarchical Activity Description

The GUI of an Activity is usually a hierarchy of views, with one or a few 
parent views containing children views, rather than a simple array of widgets.

This parent-children relationship is not accounted for in the current version 
of the Gui Tree, nor it's supported by the crawler.

Original issue reported on code.google.com by nofatclips on 31 Oct 2011 at 11:13

Activity file writing on resume

At the moment there is no need to rewrite the state file, since it is supposed 
to remain unchanged.

The listener used to save the state file on update should be suspended during 
the resume phase.

Original issue reported on code.google.com by nofatclips on 2 Mar 2012 at 2:06

Special characters

Some special characters are not correctly encoded and the resulting XML is 
invalid. For example, the s with caron in text "Roman Mašek" (in the credits 
for Open Sudoku) throws a Malformed Byte Sequence Exception when opened with 
the EFG generator

Original issue reported on code.google.com by nofatclips on 30 Oct 2011 at 4:11

Support for ExpandableListView

An ExpandableListView has at least one item that, when pressed, add more 
options ("subitems" of the pressed item) to the list.

There is no direct support for ExpandableListView: this widgets are treated as 
ordinary ListView.
Hence, after an item is selected, one of two things happen:

 * either the new state is not detected: the list with more options compare as equal to the initial list and the new options are not explored;
 * or the new state is detected and the whole list is explored anew: the crawler explores both the new options (for the first time) and the old ones (again).

The correct behaviour would be to detect the new state but only click the new 
items.

This issue is strictly related to Issue 10 since both can be solved planning 
events on the properties of the List Adapter rather than on the widgets.

Original issue reported on code.google.com by nofatclips on 6 Nov 2011 at 11:28

Support for alternate input sequences on the same event

At the moment, a single configuration of the input widgets is generated for 
each event widget.
It should be possible to fire the same event with alternate inputs (clicking a 
different checkbox, selecting a different value in a spinner, leaving all 
fields blank, etc...)

Original issue reported on code.google.com by nofatclips on 7 Nov 2011 at 10:48

Spinner Support

The simple type for Spinner is defined but there is no further support for this 
widget.

Original issue reported on code.google.com by nofatclips on 5 Nov 2011 at 4:20

Dummy Intents to emulate video, camera and other services

The crawler cannot continue the exploration when the control flow exits the 
target package of the Instrumentation.
This happens when an implicit Intent is answered by an external service, e.g. 
the camera starts in order to take a photo, Contacts starts in order to select 
a contact and so on...
Still, we could be able emulate the answer provided by these services when 
they're well known, i.e. for services that are part of the Android system. This 
will usually bring the control flow back to the application under test and 
allow the crawler to resume the exploration

Original issue reported on code.google.com by nofatclips on 16 Feb 2012 at 9:40

Rotation

Support for screen rotation as an event is missing.
In fact, we make sure that for each task, the screen starts in portrait mode.

Original issue reported on code.google.com by nofatclips on 16 Feb 2012 at 9:31

Non final strings in resources

Making the parameters in the Resources file non final would allow to extend the 
Resources class in order to use the original as a default fallback

Original issue reported on code.google.com by nofatclips on 27 Jun 2012 at 11:57

Scrollable interfaces are not fully described

There should be a way to get a complete description of an Activity even when it 
implies scrolling down the screen to retrieve all widgets.
The Extractor should be able to scroll and repeat retrieval, until the bottom 
of the screen is reached.
The Abstractor should be able to detect and remove duplicate widgets.
The Robot should be able to scroll the screen when failing to find a widget, 
and try again until the bottom of the screen is reached.

It's implied that Abstractor and Extractor communicate directly, since Android 
can't be relied to preserve the state of a widget after a scrolling
has moved it out of the screen.

Original issue reported on code.google.com by nofatclips on 20 Oct 2011 at 10:43

Automation.refreshCurrentActivity() hangs when called on Activity with animation

To reproduce the problem, crawl the Android preinstalled app "Api Demos". 
Several demos in the "Graphics" submenu reproduce the defect, i.e. 
"ColorMatrix".

The crawler will stop in ColorMatrix until the user manually presses the HOME 
button or the BACK button.

This happens because the call to Robotium function getCurrentActivity() wait 
for the UI Thread to finish, which never happens because of the animation.

Original issue reported on code.google.com by nofatclips on 20 Oct 2011 at 6:56

Detection of unexpected transition after an input is entered

Input interactions can sometimes trigger a state transition. When this occurs, 
the task should not be made into a Gui Tree trace. Instead, two new tasks 
should be scheduled: a first one missing the triggering input and second one 
with that input in place of the scheduled event.

Example: let be task T the sequence of actions (A1, A2, A3) with A3 being the 
sequence of inputs (I1, I2, I3) followed by event E, that is

T = (A1, A2, (I1, I2, I3, E))

Let's suppose that I2 is actually an event that trigger a state transition. If 
and when this is detected, trace T should be discarded immediately and two new 
tasks should be scheduled:

T1 = (A1, A2, (I1, I3, E))
T2 = (A1, A2, (I1, I3, I2))

where I2 is now obviuosly the event for trace T2.

Detection is achieved by the usual Extraction->Abstraction->Comparation routine 
iterated for all the interactions rather than only for the final event.

Original issue reported on code.google.com by nofatclips on 4 Jun 2012 at 9:13

Using no "activity description in session" requires Resuming Persistence

When the "activity description in session" parameter is false, the resume 
function is enabled, in order to generate the activities.xml file, even when 
resume is not required.

The generation of this file should be moved to the simpler persistence (Disk 
Persistence).

Original issue reported on code.google.com by nofatclips on 15 Feb 2012 at 11:29

Cascade Comparator

A Cascade Comparator would be initialized with an sequence of Comparators to be 
activated when the previous one finds a match. Every next comparator will 
usually perform a stricter comparison than the previous one, trying to find 
differences at a finer level.

A comparator which uses increasingly stricter comparation methods could solve 
several issues, such as:

- when the name of an activity is not reliable to compare it with older ones 
(namely, when there are tabs) it can still be used to check if the activity is 
new, that is: if there are no other activities with the same name, then the 
activity is new; if there's an activity with the same name, use a stricter 
comparator that ignores the name.

- sometimes is useful to compare on EditText or even TextView widgets, but 
comparing of the name of this items is senseless, since it is often supposed to 
change. At the moment, we perform id check and name check on the same set of 
widgets. With a Cascade Comparator, we could perform id checking on a set of 
widgets (with a first comparator) then perform name checking on another set of 
widgets (with a second comparator).

Original issue reported on code.google.com by nofatclips on 2 Nov 2011 at 1:27

Inputs on back event

When planning the BACK key event, inputs are not added to the task, while 
sometimes it might make sense to have them. For instance, we can set the 
preferences in the Settings and go back to the main activity.

Original issue reported on code.google.com by nofatclips on 13 Nov 2011 at 7:51

Backup of task list takes too long

Backing all the task list, one trace at a time, can take up to several minutes 
(per trace!) when there are hundreds of traces to store.
An incremental strategy that removes the scheduled task and appends the new 
planned ones would be much more efficient.

Original issue reported on code.google.com by nofatclips on 4 Dec 2011 at 9:47

Deleting temporary files on termination

Temporary files are deleted when the task list is empty, which is the default 
termination criteria. With a different criteria (e.g. terminate after 400 
traces) might be left untouched.

Original issue reported on code.google.com by nofatclips on 3 Dec 2011 at 12:25

Rating Bar Support

Support for Rating Bar is missing. Even tho' this widget is not widely used, it 
should be possible to extend the existing support for SeekBar rather than write 
new code.

Original issue reported on code.google.com by nofatclips on 12 Nov 2011 at 11:40

Manage task list from disk

The task list can become a very huge object, and keeping it in RAM would have a 
severe impact on performance.

Since we already store it on disk, we could go one step further and do 
scheduling from disk. For simple strategies (FIFO, LIFO, random) the extraction 
of a new task is straight forward and won't require the storage of metadata. 
For "smarter" strategies, some sort of information on the stored tasks should 
be kept in RAM.

Original issue reported on code.google.com by nofatclips on 4 Dec 2011 at 10:06

The name of a widget shouldn't be its value

The attribute name of the element WIDGET in the Gui Tree should not be used to 
store the value of the widget.

For example, for TextEdit the getHint() is a more suitable item to store there.

This should avoid false negatives when comparing two widgets which differ only 
by their value.

Original issue reported on code.google.com by nofatclips on 13 Nov 2011 at 7:26

Duplicated Events on ListView with separators

When planning events on a ListView, every single element is tried out, 
including separators, titles and any other non interactive (and usually non 
selectable) widget.

When the event is fired on such a widget, the next selectable element will be 
clicked instead. The same element will also be clicked on its legit event, thus 
generating twice the same trace.

An example of this happens in the SettingsActivity of Andoku.

Original issue reported on code.google.com by nofatclips on 24 Oct 2011 at 9:51

Non Random Editor

At the moment we can only insert random values in EditText widgets. This is not 
suitable for fields such as user name and password.
Testing with the wrong login might lead to discover undetected issues, but once 
they're settled we should be able to enter the correct values.

Original issue reported on code.google.com by nofatclips on 14 Nov 2011 at 4:34

Linking the image capture output from the session file

The session file should contain an attribute to link the file produced by the 
image capture facility with the corresponding activity state.

Original issue reported on code.google.com by nofatclips on 15 Feb 2012 at 11:31

Using Preferences to store parameters

There are too many parameters to manage in Resources. They should be moved in a 
Preferences object.
(Class and package name will probably need to stay in resources)

Original issue reported on code.google.com by nofatclips on 16 Nov 2011 at 4:52

Async crash can corrupt backup files

When a crash occurrs while backup is being performed, the resulting file will 
be truncated and the subsequent resume will fail.
This can be avoided by writing on a temporary file and then switching the two 
copies, or by using a separated service to write on disk.

Original issue reported on code.google.com by nofatclips on 4 Dec 2011 at 9:50

Event description is forgotten

In the final gui tree, the DESC attribute for the EVENT element is correctly 
set for the first occurrence of an event, but is often empty for all the 
(cloned) others.

Original issue reported on code.google.com by nofatclips on 3 Dec 2011 at 12:23

Number Picker Support

Number pickers should be treated as a single input.
At the moment they're seen as 2 events (the plus and minus buttons) and an 
input.

Original issue reported on code.google.com by nofatclips on 11 Nov 2011 at 8:05

Waiting on Progress Bar

There should be an option to wait on progress bars after events and/or restart. 
The mechanism must distinguish "processing" progress bar from user inputs (seek 
bars, rating bars...) 

Original issue reported on code.google.com by nofatclips on 6 Nov 2011 at 9:28

Comparator should optionally discriminate between list of different lengths or type

The comparator should optionally see as different two activities if they both 
have the same ListView but the two lists have a different number of items 
and/or have different type (single, radio, check, single/multiselect...)

Original issue reported on code.google.com by nofatclips on 8 May 2012 at 1:23

No parameter to disable exploration by equivalence

By default, only states that are not equivalent to previous states are explored.

There isn't a parameter to disable this behaviour.

A workaround to this is to use a NullComparator.

Original issue reported on code.google.com by nofatclips on 15 Feb 2012 at 3:53

Waiting when the task is over

There crawler should wait a certain amount of time at the end of a task in 
order to make possible for asynchronous crashes to occur.

The amount of time should be parametrized.

Original issue reported on code.google.com by nofatclips on 15 Feb 2012 at 3:51

Session is not saved when the instrumentation crashes

When the crawler crashes, or the jUnit method testAndCrawl() fails for any 
other reason, the remaining traces are saved from the session onto disk.

This doesn't happen when the application under test crashes and the 
instrumentation fails: the tearDown() method is never executed.

There should be another method called even when tearDown() is not called. 
Otherwise, we need a way to catch the exception thrown by the jUnit framework 
(very unlikely)

Original issue reported on code.google.com by nofatclips on 24 Oct 2011 at 9:39

AfterEventDontExplore should accept widget ID

The AfterEventDontExplore criteria works on names and descriptions; should 
accept IDs as well.

Original issue reported on code.google.com by nofatclips on 13 Nov 2011 at 11:30

Generation of a library for functional and non functional testing

The jUnit generator could easily be adapted in order to generate a different 
item of software, namely a library of testing methods to be used as elementary 
blocks while writing more complex test cases.

The methods would be named after the last event fired (i.e. clickOnSettings 
instead of testCase00087) and the amount of assertion to be performed should be 
parametrized.

Original issue reported on code.google.com by nofatclips on 30 Oct 2011 at 6:51

Different behaviour on different ListView items

All listview items are planned for a click (and optionally a long click).

This is not the correct behaviour for ListViews used for Preferences, where 
most, if not all of the elements are checkboxes and radio buttons, which should 
actually be treated as inputs.

This is due to the fact that, at the moment, the content of the ListView is 
unknown to the Planner.

Original issue reported on code.google.com by nofatclips on 30 Oct 2011 at 6:46

Bypass widget retrieval when not needed

The retrieveWidget() method of the Automation should (optionally) be called 
only when the next event has a target widget. System events (back, 
menu,rotation) can be fired immediately.

This can be used to inject an event before the main thread is idle for bug 
detecting purposes.

Original issue reported on code.google.com by nofatclips on 2 Mar 2012 at 2:04

Additional log information: remaining tasks

Title says it all

Original issue reported on code.google.com by nofatclips on 27 Jun 2012 at 11:58

Pre Crawling

There should be an option to provide a pre crawling method in order to perform 
preliminary tasks on the application under test.
At the moment, the code have to be put directly in the Engine class.

Original issue reported on code.google.com by nofatclips on 13 Nov 2011 at 3:38

Crash is not always due to the running trace

When a crash is caused by a task running in background, it may occur after the 
trace that launched the task ended.
In this case, the crash is attributed to the task running at the moment of the 
occurrence.
This causes many problems:

1) a "good" trace is marked as crashed
2) a "bad" trace is marked as not failed
3) the good trace will not be explored further since it's supposed to crash
4) the bad trace will be explored further causing more (asynchronous) crashes 
and more unexplored (but actually good) branches

Original issue reported on code.google.com by nofatclips on 4 Dec 2011 at 9:44

Image Capture for intermediate events

At the moment the image capture only works for the final state of a task. It 
could be desirable to take a screenshot before or after each one of the events 
the task is comprised of.

Original issue reported on code.google.com by nofatclips on 15 Feb 2012 at 11:36

Description for Events on complex ListViews

The description of the "selectListItem" Event is taken from the selected item 
if the item has a text.

When the Item is a Layout, the description is missing, since the Layout is not 
a TextView.

The crawler should search the Layout for TextView children and took the 
decription from one of them.

Original issue reported on code.google.com by nofatclips on 24 Oct 2011 at 9:45

Saving equivalent state descriptions

When description is stored in a separate file and comparation is active, when 
the final activity of a trace compares equal to a previous one, its description 
is discarded.
This leads to the generation of assertions in the JUnit test cases that will 
never be true, because referring to an equivalent, yet not equal, state 
description.

Original issue reported on code.google.com by nofatclips on 20 Mar 2012 at 11:33

No need to load activities when using Null Comparator

The activity states are not needed when comparation is disabled and should be 
avoided since the NullComparator yields a huge activities file.

Original issue reported on code.google.com by nofatclips on 15 Feb 2012 at 3:54

Seek Bar Support

There is no support for the SeekBar widget

Original issue reported on code.google.com by nofatclips on 5 Nov 2011 at 4:18

Handling/Avoiding anomalies

When a bug or a change in the state of the application under test (or any other 
cause) results in disappearing /disabling the widget on which an interaction 
should be performed, the crawler will crash with a "Null Pointer" exception.

At the moment, the only workaround is to avoid all operations which may cause a 
widget to disappear. A better solution should be provided, so that the crawler 
may continue its work or close gracefully.

Original issue reported on code.google.com by nofatclips on 27 Oct 2011 at 2:41

Customizable Log

A logger which is able to save the log session to disk would come in handy when 
dealing with crashing applications.

Original issue reported on code.google.com by nofatclips on 27 Oct 2011 at 2:44

GridView Support

There is no support for the GridView widget.

Original issue reported on code.google.com by nofatclips on 5 Nov 2011 at 4:19