Closed Bug 839134 Opened 10 years ago Closed 10 years ago

adb seems to be non-enablable when OTAing across bug 836103 fix time


(Firefox OS Graveyard :: General, defect)

Gonk (Firefox OS)
Not set


(blocking-b2g:-, b2g18+ fixed, b2g18-v1.0.0 wontfix, b2g18-v1.0.1 fixed)

blocking-b2g -
Tracking Status
b2g18 + fixed
b2g18-v1.0.0 --- wontfix
b2g18-v1.0.1 --- fixed


(Reporter: dhylands, Assigned: dhylands)




(1 file)

Bug 836103 landed on b2g18 on Jan 30 around 11am, and on the v1.0.0 stream around 2pm.

The observation (by tchung) is that flashing an unagi with a pre-jan 31st image and OTA updating to todays image leaves the phone in a state where adb can't be enabled.

I'm filing this bug to track the investigation and the fix once we figure out what's going on.
And just to state the obvious,  I do have Settings > Developer > Remote debugging checked on.   I've also unplugged/replugged USB, closed/reopened Settings App, and even restarted the phone from scratch.   The Remote debugging checkbox stays checked, but adb devices always returns null.

host-7-31:scripts tchung$ adb devices
List of devices attached 

host-7-31:scripts tchung$ 

Build info from device information screen:
* Git commit: 2013-02-07 11:05:46
BuildID: 2013020707202.

NOte: we also retested an update from yesterday's build to today (02-06 -> 02-07), and adb works as expected.
OK I think I've sort of reproduced the problem (but the opposite way).


Starting conditions:
- adb was enabled (I had logcat running)
- Remote debugging was off

I downloaded and flashed:

I went through the FTU app, and the only thing I changed was that I connected to my Wifi network.

Very shortly after booting up, I was presented with an update. I unselected the app update and downloaded/applied. The update that was downloaded was (taken from logcat): to /mnt/sdcard/updates/0/update.mar

My updated was applied and b2g restarted. The interesting thing is that adb never got disabled. I went into the settings app and toggled the remote debugger setting and no change in adb was observed.

So I think this reproduces the problem (remote debugger setting doesn't seem to be affecting adb) and tchung somehow started with adb disabled.

Now to figure out why...
Ok. It seems that this line (from gecko/b2g/chrome/content/settings.js)

    if (Services.prefs.getBoolPref('marionette.defaultPrefs.enabled')) {

throws an exception:

[Exception... "Component returned failure code: 0x8000ffff (NS_ERROR_UNEXPECTED) [nsIPrefBranch.getBoolPref]"  nsresult: "0x8000ffff (NS_ERROR_UNEXPECTED)"  location: "JS frame :: chrome://browser/content/settings.js :: <TOP_LEVEL> :: line 214"  data: no]

And this causes adb to be left in whatever state it was in.
This adds a try/catch block around the query of marionette.defaultPrefs.enabled.
Attachment #711427 - Flags: review?(fabrice)
Nominating for tef? since this affects our dogfooders
Blocks: 836103
blocking-b2g: --- → tef?
Attachment #711427 - Flags: review?(fabrice) → review+
blocking-b2g: tef? → -
tracking-b2g18: --- → +
Comment on attachment 711427 [details] [diff] [review]
Add try/catch around query of marionette preference

[Triage Comment]
Tef wouldn't block release on this, but tracking since it's important to our dogfooding ability and approving for uplift to the mozilla-b2g18 branch for 1.0.1 builds to pick up.
Attachment #711427 - Flags: approval-mozilla-b2g18+
Closed: 10 years ago
Resolution: --- → FIXED
Batch edit: Bugs fixed on b2g18 after 1/25 merge to v1.0 branch are fixed on v1.0.1 branch.
You need to log in before you can comment on or make changes to this bug.