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)
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.
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.
Julian Dolby
Juergen Graf
Tobias Blaschke
Martin Mohr