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 , Android Studio must inject monitoring logic into your compiled .

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:

  • 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 -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

(as an aside, testing to ensure that the files in internal storage are what
you expect is a really cool test)

From a 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.

Find out about new posts on the CommonsBlog via the Atom feed, or follow @CommonsWare on Twitter!


Source link

No tags for this post.


Please enter your comment!
Please enter your name here