Question: Enabling Flipper for non debuggable release builds

Hi!

The QA team in my company regularly used Stetho in internal dogfood builds distributed through the play store. But we have tried to replicate the setup with Flipper and we weren’t able: the library would work fine, but the desktop app would refuse to communicate with an app not in debuggable mode.

04-28 11:10:38.763 17157 17292 I flipper : flipper: Desktop failed to provide certificates. Error from flipper desktop:
04-28 11:10:38.763 17157 17292 I flipper : Android app com.myapp is not debuggable. To use it with Flipper, add android:debuggable="true" to the application section of AndroidManifest.xml

By being distributed internally through the play store, we cannot use debuggable builds. Is there any way that check could be disabled so that we can run Flipper for our internal dogfood release builds?

Thanks!

[jknoxville]

Provided I’m not forgetting anything, it would just work and you wouldn’t need to change any desktop code.

You could test this fairly easily by doing the following:

• Run flipper alongside a debuggable app (your debug build where flipper is working).
• Extract the files from the mobile apps container (replace com.facebook.flipper.sample with your apps package):
  • ./scripts/debugging/android_sonar_dir.sh ls com.facebook.flipper.sample will list the files you need. Do this while the app is successfully connected to flipper to ensure you’re copying a working set of files.
  • ./scripts/debugging/android_sonar_dir.sh pull com.facebook.flipper.sample app.csr app.csr will pull a single file. Do this for each file listed by the previous command.
• Now you’ve got a bunch of client files that will allow an app to connect to your flipper instance. Get your non-debuggable android app to write these files to files/sonar/ before it starts the flipper client, then it should bypass the certificate exchange (and thus bypass the need to be debuggable) and connect straight to your desktop app.

Things you need to know:

• The desktop app creates new certificates for itself when they don’t exist, or if it notices something wrong with them (like they’ve expired). If this happens, your deployed client certs won’t match anymore. This should be infrequent but can happen.
• If you’re going to use the same client certs in your mobile build for several people, the files their desktop apps use (~/.flipper/certs/) will all need to accept that client, so you’ll have to take care of securely deploying them to your testers computers, rather than letting flipper generate them itself.
• Don’t leak those desktop files. They will allow anyone to connect to your built app.
• As mentioned by passy we only use (and support) Flipper in debug builds. While I’m not aware of any, it’s possible that there are other things that prevent it from working in release builds, so you’ll be in uncharted waters there and we may not be able to help further.

[jknoxville]

Hi @mrmans0n,

passy is right, it’s a requirement for the adb run-as command which we use to secure the connection. This prevents other apps or websites from being able to connect to your app.

If you don’t want to root, an option would be to manage your own server and client certificates, instead of letting flipper manage them for you automatically. Right now flipper desktop creates self-signed certs in ~/.flipper/certs, and it also writes a client cert into files/sonar within the mobile apps data partition.

If you deployed the contents of those files to desktops before flipper runs, and also into your mobile app (it could write them on startup before starting the flipper client) then that would work, but bear in mind that anyone in possession of the app files (~/.flipper/certs) will be able to connect to your app.

There’s one more option, if you can test on rooted devices or emulators. It should be possible to make Flipper work even on non-debuggable apps, because we could use su instead of run-as, like was done for non-application use cases in f4b0898de540c95457abe783f03e866c5d846468 but this would require some more involved changes in the desktop app code.