added virtual edge to AsyncTask.onCancelled(java.lang.Object)

[jpstotz]

The virtual edges for android.os.AsyncTask methods onPreExecute() onProgressUpdate(java.lang.Object[]) and onPostExecute(java.lang.Object) were already defined, but onCancelled(java.lang.Object) is missing.

As we already include onProgressUpdate without a check if publishProgress is ever called we should also add a virtual edge for onCancelled (without checking if cancel(boolean) is ever called on the task.

The method signature has been verified in a practical test.

[StevenArzt]

@jpstotz Dein MR hat Conflicts

[jpstotz]

@StevenArzt Yes, I have seen that, will fix that.

The reason I have not fixed the conflict yet is that on a second thought connecting AsyncTask.execute with onCanceled is may be not the best way. I made some experiments with connecting AsyncTask.cancel(boolen) with onCanceled which would be the correct approach.

Unfortunately Soot does not allow to use a full signature with an instance entry in the virtual edges XML file. In my opinion the whole virtual edges system is pretty dangerous as all instance methods are only connected based on their subsignature totally ignoring the class they are implemented in. For subsignatures that are pretty unusual like android.os.AsyncTask execute(java.lang.Object[]) the chance is very low that a different method has the same signature but is unrelated to AsyncTask, but for a signature like boolean cancel(boolean) a false positive is pretty likely, you just need a second method with void onCancelled(java.lang.Object as subsignature in the same class.

Therefore I searched for an easy way to improve the whole system but as usual this isn't that easy with soot...

[StevenArzt]

@jpstotz We check the base object, so we ensure that it's the same instance on which the methods are called. That's why we have the reference types (base/parameter) in the XML. We don't have full signatures, so we can't distinguish between two classes that have the same methods, but only one of which we want to treat as a callback. However, that doesn't make the analysis object-insensitive from there on, it just means that we follow the objects for potentially spurios methods that shouldn't be callbacks.