Now there are four structural models:
* SequentialAndroidModel: No loops
* SingleStartAndroidModel: User Interaction on a single component
* LoopAndroidModel: Stuff goes into background and comes back
* LoopKillAndroidModel: Restart of components due to low memory
Code oftain sets the action of an Intent after it's constructor. Until
now a call to such a setter caused the Intent to become "unbound"
(conservative).
This approch allows setting the target once for each Intent - only on
the second call the Intent gets unbound.
This new variant could be dangerous: Setting the target in a branch of
execution may be invalid. This should be detected - no guarantees so!
Methods in question are:
* Intent.setAction
* Intent.setComponent
* Intent.setClass
* Intent.setClassName
Before the Intent would only have been set by calling .attach (if
doBootSequence is enabled). Attach is only called when the modell is
filled with instructions.
This new variant calls setIntent when creating the wrapper for the model
(getMethodAs). This is much better!
* Create IntentContext even if no info available.
This is necessary to also track the start of unknown targets.
* Invalidate the target of an Inten upon a call to Intent.setAction
or Intent.fillIn
Additionally tidied up the classes a bit.
The SystemServiceModel creates and returns a new Instance of the
requested Service (if known).
TODO: We should use a single "global" instance per service instead.
Building the CFG with a SSAGotoInstuction was buggy: Oftain the wrong
jump-target was selected. This has bin fixed.
Additionally InducedCFG now automaticly breaks the basic-block at the
jump-target.
Jumping to Phi-Instructions however is still unsupported (as they are
not part of the cfg-instructions)
There was (and is) the posibility of an endless-loop when looking up the
targets of Intents. Added an evil hack to at least prevent the most
obvious one.
The Analysis has problems with the IntentSender class: Invalid DefUse an
an Init-Call.
The Intent-Starters, that use IntentSender have been made optional.
However disabling them does not help.
Currently the only solution to this problem is adding IntentSender to
the exclusions.txt
Setting the Instantiation-Behavior of Package:
Landroid/support/v4/view
To REUSE causes the following Endless-Recursion in JoDroid:
interproc: computing local killing defintions... done
Building utility edges Exception in thread "main" java.lang.StackOverflowError
at java.util.HashMap.put(HashMap.java:389)
at org.jgrapht.graph.AbstractBaseGraph.addEdge(Unknown Source)
at edu.kit.joana.util.graph.AbstractJoanaGraph.addEdge(AbstractJoanaGraph.java:50)
at edu.kit.joana.wala.core.DependenceGraph.addEdge(DependenceGraph.java:76)
at edu.kit.joana.wala.core.joana.JoanaConverter$UtilityEdgeWalker.discover(JoanaConverter.java:344)
at edu.kit.joana.wala.core.joana.JoanaConverter$UtilityEdgeWalker.discover(JoanaConverter.java:325)
at edu.kit.joana.wala.core.graphs.GraphWalker.dfs(GraphWalker.java:55)
at edu.kit.joana.wala.core.graphs.GraphWalker.dfs(GraphWalker.java:63)
at edu.kit.joana.wala.core.graphs.GraphWalker.dfs(GraphWalker.java:63)
at edu.kit.joana.wala.core.graphs.GraphWalker.dfs(GraphWalker.java:63)
...
As this package contains System-provided android-components it should however be marked REUSE in order to be able to read back values when these types are used.