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.
AndroidPreFlightChecks provides some checkups on the settings before
bulding the Livecycle.
The checks have to be invoked explicitly and issue warnings in the log.
Governed by AndroidEntryPointManager.setDoBootSequence generate some
coarse Android-environment before starting the LiveCycle-Model.
Some action is taken to attach the Android-Context to Components - much
is still missing there though.
Thin context is mainly useful when starting Intents of an external App.
Whenever an Intent is encountered while building the CallGraph a
WALA-Context is generated for it. If a new Android-Component is started
and the Context is sufficient the start-function will call a new type of
model, the MicroModel.
The MicroModel resemples the livecycle of a single Android-Component.
Whenever the start of an intent is encountered the start-function is
replaced by a call to UnknownTargetModel.
UnknownTargetModel will call a restricted android-model (i.e. one that calls only all
Activities). This restricted model is known as MiniModel.
It will also call ExternalModel which does nothing special.
Generate a synthetic AndroidModel in AndroidModelClass.
The model will contain Android EntryPoints in a sorted manner. However
no special handling (loops) are inserted yet.
Intents are not processed at all - thus have to be marked insecure.
Parameters to Androids EntryPoint-Functions may be either marked CREATE
or REUSE. Added these markers and made them availabel through
AndroidEntryPointManager.
Using a SummarizedMethodWithNames instead of a normal one enables human
readable variable names in WALA-Synthetic methods. This should help
when debugging.
Depending on the method used generating an AnalysisScope failed for
Android-Apps. Especially depending on wheater data was used from a
jar-resource or depending on exclusions.txt
CAUTION: Now you have to make sure that the provided android lib actually contains all standard
java classes (e.g. java.lang.Object); WALA will complain and crash if this is not the case
Tobias Blaschke
Martin Mohr
Juergen Graf