Android Studio 3.0: What "Injecting Monitoring Logic" Means
Michael Comella published a nice bit of analysis last week, showing the ramifications of this innocuous sentence in the documentation for the Android Studio 3.0 profiler:
To show you advanced profiling data, Android Studio must inject monitoring logic into your compiled app.
When you run your app from Android Studio, in addition to deploying the APK, Android Studio also pushes three files to the root of your app’s portion of internal storage:
libperfa_x86.so
perfa.jar
perfd
These will be pushed over if:
-
You run the app from the Run option in the IDE (versus installing the app by other means)
-
You run the app on an Android 8.0+ device (and possibly on older ones as well, if you opt into that)
-
Have ever had the Android Profiler tool window open in Android Studio since you started up this copy of the IDE
It would appear that these three files contain code that gets injected into your app’s process as part of profiling it, in line with the quoted sentence.
Tactically, this can screw up some tests. Mr. Comella found out about the problem when testing Firefox Focus, Mozilla’s privacy-centric browser for Android. One of the tests involves ensuring that no extra stuff gets left behind after a browsing session, and the test tripped up over these unrecognized files.
(as an aside, testing to ensure that the files in internal storage are what you expect is a really cool test)
From a security standpoint, on the one hand, there does not appear to be an immediate problem. In my testing, these files are not packaged into the APK itself, but instead get pushed over separately. Hence, these files should not make it into your production environment. Still, I really hope that whatever mechanism Android Studio uses to inject this stuff is adequately secured.
My only complaint is that we cannot turn this off, short of closing up Android Studio, re-opening it, and making sure not to touch the Android Profiler tool. If the Profiler needs this injected stuff to work, that’s fine, but there still should be better developer-level control over the code injection. With luck, this will get addressed sometime.
So, my hat’s off to Mr. Comella for documenting this, and to Nathan Freitas for raising awareness further.