In bug 1449052, add-ons team is plotting removal of support for bootstrapped extensions, which impacts ADB Helper. This is probably a good moment to reevaluate what we want ADB Helper to be today. The main features of ADB Helper are: * One-click install of `adb` binaries (packaged inside the add-on) * Since these are somewhat large, the separate add-on reduces Firefox download size * JS client code to help Firefox talk to the `adb` binary, for tasks like: * List Android devices with Firefox * Connect to Firefox for Android to enable debugging sites Here are some ideas for what we could convert to: A. A WebExtension with bundled Experiment which can run privileged code * This seems the most similar to ADB Helper as it is today * An demo add-on with this approach: https://github.com/rhelmer/webext-experiment-crashme/ B. Move the "download binaries" piece into Firefox itself (instead of being an add-on) * On some user action, download `adb` for use by Firefox * The JS glue code is small and could likely be included in all builds There are surely other pathways as well... feel free to suggest your own options.

I've started looking this.

:aswan suggested to me on IRC is that the new extension can contain a JSON file and devtools extract it. I can imagine the JSON file looks like this; { "Linux": { "x86": [ "linux/adb" ], "x86_64": [ "linux64/adb" ] }, "Darwin": { "x86_64": [ "mac64/adb" ] }, "WINNT": { "x86": [ "win32/adb.exe", "win32/AdbWinApi.dll", "win32/AdbWinUsbApi.dll" ], "x86_64": [ "win32/adb.exe", "win32/AdbWinApi.dll", "win32/AdbWinUsbApi.dll" ] } } And then, in devtools, we use this just like something like this; theJSONInfo[Services.appinfo.OS][Services.appinfo.XPCOMABI.split("-")[0]] Then we can extract each files (e.g. adb.exe) from the extension in devtools. I believe with this approach, we don't need any experiments in the extension. Also note that an advantage of this approach (rather than downloading binaries) is that the extension is signed by @mozilla.org (:arai told me it).

Here is the very beginning patch. My plan here is to port each feature in the old extension to devtools as a single commit respectively. E.g. 1) unpacking adb binary, 2) launching the binary, etc. etc. I am also planing to add unit tests (xpcshell tests) in each commit. But I am stuck at the very beginning of this patch. :/ In this patch, I am trying to extract 'adb.json' in the new extension, but it doesn't work in the xpcshell test added in this patch. The code in question actually works in about:debugging content. When the code is invoked in the xpcshell test, ResolveURI [1] in SubstitutingProtocolHandler::NewChannel2() fails. I am suspecting 'moz-extension' protocol isn't registered in the test, but I have no idea how to do that yet. [1] https://hg.mozilla.org/mozilla-central/file/ff8505d177b9/netwerk/protocol/res/SubstitutingProtocolHandler.cpp#l259

Moving major about:debugging ng work into milestone 1, leaving m0 for prior bugfix work.

Andrew, what is the current target date to remove bootstrapped extensions?

The end of the 64 Nightly cycle, currently scheduled for 10/22

This turned into a meta bug, unassigning.

Tracking the individual dependencies instead of the meta bug.

All the dependencies have been resolved.

\o/ Thank you, Julian!