Planning to add adb and fastboot to Chrome OS images.

[Alex Vallée]

Hi chromium-os-dev,

I'm planning to add support for developers using chromebooks to be able to debug their phones (and ARC apps which the adb daemon active) directly on their chromebook in order to solve crbug.com/444223.

The details of this are in this design doc.

Cheers,

Alex.

[Chris Masone]

It would be helpful if you'd fill out the remaining sections of the doc, including alternatives considered, testing plan, and security considerations.

--
--
Chromium OS Developers mailing list: chromiu...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en

[Reilly Grant]

Have you considered builting this on top of existing Chrome Apps APIs?

[Alex Vallée]

The 2 main reasons I did not consider the Chrome Apps API was that it would involve keeping a fork of adb over the android repo with significant changes. Also, it looks like a window would need to stay open to keep the adb server running between commands which I expect to come through crosh.

[Bartosz Fabianowski]

On 04/20/2015 05:33 PM, Alex Vallée wrote:
> The 2 main reasons I did not consider the Chrome Apps API was that it
> would involve keeping a fork of adb over the android repo with
> significant changes. Also, it looks like a window would need to stay
> open to keep the adb server running between commands which I expect to
> come through crosh.

There are workarounds for the latter requirements, and we are working on
a fix that will ensure an event page is not shut down as long as it is
hosting a running NaCl module (I presume you would be running adb via NaCl).

- Bartosz

>
> On Mon, Apr 20, 2015 at 11:25 AM, Reilly Grant <rei...@chromium.org
> <mailto:rei...@chromium.org>> wrote:
>
> Have you considered builting this on top of existing Chrome Apps APIs?
>
>
> On Mon, Apr 20, 2015, 8:15 AM Chris Masone <cma...@chromium.org
> <mailto:cma...@chromium.org>> wrote:
>
> It would be helpful if you'd fill out the remaining sections of
> the doc, including alternatives considered, testing plan, and
> security considerations.
>
> On Mon, Apr 20, 2015 at 8:09 AM Alex Vallée
> <ava...@chromium.org <mailto:ava...@chromium.org>> wrote:
>
> Hi chromium-os-dev,
>
> I'm planning to add support for developers using chromebooks
> to be able to debug their phones (and ARC apps which the adb
> daemon active) directly on their chromebook in order to
> solve crbug.com/444223

> <https://code.google.com/p/chromium/issues/detail?id=444223>.

>
> The details of this are in this design doc

> <https://docs.google.com/document/d/1ynFX-yXCRqrrTILqMcwB3DI-lt9jX1XQuvTC7gv3FVg>.

>
> Cheers,
> Alex.
>
> --
> --
> Chromium OS Developers mailing list:
> chromiu...@chromium.org

> <mailto:chromiu...@chromium.org>

> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en
>
> --
> --
> Chromium OS Developers mailing list:

> chromiu...@chromium.org <mailto:chromiu...@chromium.org>

[Reilly Grant]

I was actually going to suggest building an Android Debug Tools app that included its own shell with adb and fastboot as well as anything else that would be useful for debugging ARC apps or real devices.

Were you planning to make these commands available outside of developer mode or not? I think in general we've been trying to cut down what is available through crosh and adb has a pretty large attack surface.

[Jorge Lucangeli Obes]

On Mon, Apr 20, 2015 at 8:33 AM, Alex Vallée <ava...@chromium.org> wrote:

The 2 main reasons I did not consider the Chrome Apps API was that it would involve keeping a fork of adb over the android repo with significant changes. Also, it looks like a window would need to stay open to keep the adb server running between commands which I expect to come through crosh.

Why would you need significant changes to adb? Your solution seems to imply adb will always be installed and even running on all types of images, even when it's not required. Why is necessary?

[Alex Vallée]

Bartosz:

So you're suggesting this be built as an app with the adb/fastboot binaries as nacl modules. The TCP implementation would need to be rewritten to PPAPI and bridging USB from the javascript API.

Reilly:

Use hterm and have adb command line (same nacl module) call out to the server above?

--
You received this message because you are subscribed to the Google Groups "App Runtime for Chrome" group.
To unsubscribe from this group and stop receiving emails from it, send an email to arc-eng+u...@google.com.
To post to this group, send email to arc...@google.com.
To view this discussion on the web visit https://groups.google.com/a/google.com/d/msgid/arc-eng/55351D57.4060307%40chromium.org.
For more options, visit https://groups.google.com/a/google.com/d/optout.

[Reilly Grant]

Yes to all of the above though a native Pepper USB API is not out of the question. I just haven't seen any interest.

[Badhri jagan Sridharan]

Hi Alex,

We(Android Systems) already have an approved intern project to get adb and fastboot working on ChromeOS.

The intern is scheduled to start first week of May.

Is there any way we can prevent the duplication of effort ?

I also previously spoke to Bill Napier (who had an intern working on chromeOS flash station last summer),

just to make sure that there is no effort duplication.

Regards,

Badhri.

[Kevin Cernekee]

On Mon, Apr 20, 2015 at 8:08 AM, Alex Vallée <ava...@chromium.org> wrote:
> Hi chromium-os-dev,
>
> I'm planning to add support for developers using chromebooks to be able to
> debug their phones (and ARC apps which the adb daemon active) directly on
> their chromebook in order to solve crbug.com/444223.

Hi Alex,

Others in the thread have suggested implementing this as a Chrome app.
Is there anything in these projects that you could leverage?

https://chrome.google.com/webstore/detail/adb-shell-for-chrome/njhehnieenekbompacofnhlljnobgcga

https://chrome.google.com/webstore/detail/chromeadb/fhdoijgfljahinnpbolfdimpcfoicmnm

The other thing to consider is: when you "adb {push,pull,sideload}" or
"fastboot flash" a file, where will it be stored? Can a straight port
of the command line tools access files on Google Drive or SFTP? If
you're flashing 500MB system images from the Chromebook, what are the
logistics of transferring those files over from your build system?

> The details of this are in this design doc.

FYI, this page isn't currently accessible using a plain gmail account
(but this conversation is on a public list). Could you please update
the sharing settings to make it open to all?

[Alex Vallée]

Hi Badhri,

How similar is your intern project compared to this new design. Would this be a good starting point for your intern or is this very different than what you are planning?

The chrome flashstation app is really cool and well polished, however it appears to be restricted to Googlers only, I don't know if there's a way it could be published externally or if we'd be happy if someone downloads and update file and flashes it through the app that implements fastboot.

Alex.

--

[Badhri Jagan Sridharan]

Yes Alex, seems pretty much similar to what we were planning to do.. 

Motive being not to fork adb/fastboot implementation altogether, as it might turn into a maintenance nightmare. 

(Since, we only have one flavor of adbd running on the android device side, which works for all the HOST OS's : linux/windows/mac)

But, I was not aware of the fact that NACL does not support USB API's and we have to rely on chromeUSB API's

(similar to what flashstation does, I believe). However, the device discovery part from the host side can still be the same as it only requires scanning /dev/bus/usb node.

So, at least the device discovery part of the usb_linux.c can be reused I think.

Regards,

Badhri.

[Badhri Jagan Sridharan]

Also does adb and fastboot NACL binaries have to be generated for every specific target i.e. ARM, X86 etc ?

Came to know about the existence of "PNACL" which enables creating portable native executable.   

I don't have a concrete idea of how it works, but, is it something that can be investigated ? 

[Alex Vallée]

Responses inline.

Cheers,

Alex.

On Mon, Apr 27, 2015 at 7:26 PM, Badhri Jagan Sridharan <bad...@google.com> wrote:

Also does adb and fastboot NACL binaries have to be generated for every specific target i.e. ARM, X86 etc ?

Came to know about the existence of "PNACL" which enables creating portable native executable.   

I don't have a concrete idea of how it works, but, is it something that can be investigated ? 

PNaCl is mainly for deploying plugins on the drive-by web. Chrome goes and compiles the arch specific nexe from the pexe before running. When publishing an app on the web store, I think it's recommended to ship nexes. Building the each platform is just a matter of running the build steps with the 3 different gcc-based toolchains, then a manifest (.nmf) describes which nexe files to load for which architecture.

 

On Monday, April 27, 2015 at 4:10:33 PM UTC-7, Badhri Jagan Sridharan wrote:

Yes Alex, seems pretty much similar to what we were planning to do.. 

Motive being not to fork adb/fastboot implementation altogether, as it might turn into a maintenance nightmare. 

Agreed, another fork of adb is not what we want. See the web for many different partial implementations in javascript and other languages. 

(Since, we only have one flavor of adbd running on the android device side, which works for all the HOST OS's : linux/windows/mac)

Well, the protocol itself doesn't change, but the adbd binary will be arm or intel depending on which phone/emulator it's running on. Similar thing going on for Chrome.

But, I was not aware of the fact that NACL does not support USB API's and we have to rely on chromeUSB API's

(similar to what flashstation does, I believe). However, the device discovery part from the host side can still be the same as it only requires scanning /dev/bus/usb node.

So, at least the device discovery part of the usb_linux.c can be reused I think.

Under NaCL, the filesystem is sandboxed, and you won't be able to open() files under /dev at all. usb_linux is completely out of the picture in our situation. Fortunately, what needs to be implemented are discover, add and remove devices from the server registry and implement usb_read and usb_write as used by the server. What you need is a small stub that listens for messages from the js side, response to add, remove, read and write messages.

All discovery happens in javascript, the API does have filtering by vid/pid, interface {class,subblass,protocol}. The flow is, click a button to show a dialog (filtered by adb/fastboot interfaces.) The user selects all the ones he wants and chrome adds permission to all those devices, and returns the list of selected devices to the app. Once authorized, the app will receive device connected/disconnected events which it can use to send messages to the native side that a new device is discovered/removed.

--
You received this message because you are subscribed to the Google Groups "App Runtime for Chrome" group.
To unsubscribe from this group and stop receiving emails from it, send an email to arc-eng+u...@google.com.
To post to this group, send email to arc...@google.com.

To view this discussion on the web visit https://groups.google.com/a/google.com/d/msgid/arc-eng/7e1e2765-9c7e-4cc8-8f3e-a223a469b0ba%40chromium.org.

[Mike Frysinger]

i don't think your characterization of pnacl-vs-nacl is correct:

https://developer.chrome.com/native-client/nacl-and-pnacl#when-to-use-pnacl

i can't think of a reason to not use pnacl for adb.  it's transparent both to the developer and the user, so why waste time on nacl ?

-mike

[Alex Vallée]

Hi Badhri,

Has your intern started? I have an adb server almost working on my person git-on-borg instance. I could work with him this week to hand it off to him or her before I leave on paternity.

Thanks.

On Tue, Apr 28, 2015 at 11:32 AM, Mike Tsao <mi...@google.com> wrote:

PNaCl has a noticeable translation time on first load, including first load of any updates. For one of my hobby apps, a 1MB binary takes maybe 6-10 seconds on a Chromebook. I bet an app could trigger it from the event page, in the background, after each version update, so that the user wouldn't actually be blocked on translation. But I haven't tried doing that.

All that said, I do ship my personal Chrome Apps as PNaCl, not NaCl. Compilation time, including SDK setup time, is much faster, the upload to CWS is smaller, and I like using cool technology.

To view this discussion on the web visit https://groups.google.com/a/google.com/d/msgid/arc-eng/CAAbOSc%3DYTENvjJKzUfSxA4f_H4kx7OnXGCuTGgQh9Da%2BbtyiGg%40mail.gmail.com.

For more options, visit https://groups.google.com/a/google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "App Runtime for Chrome" group.
To unsubscribe from this group and stop receiving emails from it, send an email to arc-eng+u...@google.com.
To post to this group, send email to arc...@google.com.

To view this discussion on the web visit https://groups.google.com/a/google.com/d/msgid/arc-eng/CAHFu6rDOmLRzrFWwNH2mjX%3Dvgika9mF0ZzXuYphvtO67ZDdixQ%40mail.gmail.com.