1456606 - Add support for capturing profiles locally on Android without having a computer connected to the phone

Status: NEW

(Core :: Gecko Profiler, enhancement, P2)

Description

[(no longer active)]

In order to be able to capture profiles from real-life browsing on Android, we need to be able to capture and upload profiles locally on Android without the device being connected to a computer.  This will allow people to upload profiles when something is slow as they're using Firefox on the go.

Markus, Jeff and I talked a bit about what's needed in order to do this today, I'm filing this bug as a tracking bug for this effort so that other bugs can be filed under it.

Comment 1

[Randell Jesup [:jesup] (needinfo me)]

This is going to be critical to Mobile Quantum Flow efforts.

We're going to need a UI button in Klar to trigger profile capture-and-upload.  We'll need a bug (or GH issue) for that part.

Strawman for the process:  Profiler is always running (perhaps some Setting element causes it to start on startup/restart).  Hit button, profile is captured and pops up a form to add any notes, pre-filled with the URL and system info, and an email address to CC it to (on submit it would launch an email intent with the data from the form and the URL to the profile).  Simultaneously it starts symbolifying (bug 1457481).  The form would show a privacy warning before uploading the profile.

Alternatives welcome!

Add markers for when intents are received and when it goes to foreground/background (and mem pressure, etc).

Bonus would be something like about:profiles (list of profiles you've uploaded - for GV and for desktop), with option to tell server to delete them, or to copy the URL to the clipboard (for email/etc).

Comment 2

[Randell Jesup [:jesup] (needinfo me)]

Refined strawman:
Beta only.

Checkbox in Settings to enable profile capturing by default (probably with a warning about privacy).  This will enable the profiler at startup (and when switched on).

Entry in menu to report performance problems.  When selection, captures the profile (or at least freezes the profiler), and asks if the user wants to upload the profile, with a big block of warning text about it including PI info and URLs, etc.  

If the user say to upload it, it uploads, and at the same time it pops a email intent with the URL the profile will have, the URL of the loaded page when they selected Report Performance Issue, and "Please add any information helpful in understanding what the problem was below".  

When the hit send, it goes to a mailing list ([e-mail] or whatever), which mozilla engineers can be added to.  Since there's PI data there, we may need to vet requests to join the list, even though the user has agreed to expose the data.


Note: the profiles may include unexpected (by the user) PI data.  we may need to keep the actual profiles behind a LDAP/auth0 login wall, in which case they can't be on the same server as "normal" profiles.  OTOH, we are asking explicit permission.  We might want to look at what is actually captured before deciding.  Using an alternate server might be easy, or might be a major problem.

Deploying any of this to non-mozilla-employes/etc will require Data Steward approval.  We need this, though, even if it's only for internal use.

Comment 3

[Randell Jesup [:jesup] (needinfo me)]

Note that we'll need to symbolicate the profiles on load instead of before saving.  mstange is working on support for this (bug?)

Comment 4

[Panos Astithas (he/him) [:past] (please ni?)]

It is the second dependency of this bug, bug 1457481.