Closed Bug 1501867 Opened 6 years ago Closed 3 years ago

Need to constantly |adb unroot| between |mach mochitest| and |mach install|

Categories

(Firefox for Android Graveyard :: Testing, enhancement, P3)

enhancement

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: botond, Unassigned)

Details

It seems that whenever I run |mach mochitest|, the test harness switch adb to root mode.

However, |mach install| only succeeds when I'm *not* rooted, so whenever I'm iterating on a test by changing code, reinstalling and re-running, I need to run |adb unroot| between calls to |mach mochitest| and |mach install|.

Is there a way this could be avoided?
How does |mach install| fail? What's the error message/output?
One thing I've noticed is that when I build geckoview_example via ./mach gradle geckoview_example:installLocalWithGeckoBinariesNoMinApiDebug it will install the apk without using -g and I have to manually adb install -r -g it afterwards. Maybe this is another instance where adb install -r -g should be used by mach?
Although in the latter case isn't it Gradle doing the actual installation as well and mach's involvement only amounts to launching the gradle command itself?
(In reply to Bob Clary [:bc:] from comment #2)
> afterwards. Maybe this is another instance where adb install -r -g should be
> used by mach?

Last I checked, the mobile team wanted mach to install without -g so that developers would need to manually grant runtime permissions, just like real-world users (devs have the same UI experience, can verify which permissions are required, etc). That's why the mach test commands rely on grant_runtime_permissions().
(In reply to Geoff Brown [:gbrown] from comment #1)
> How does |mach install| fail? What's the error message/output?

 0:00.53 /usr/bin/make -C . -j16 -s -w install
 0:00.54 make: Entering directory '/home/botond/dev/mozilla/out-of-tree-objdirs/refactoring-android-arm'
 0:01.08 [  0%] /data/local/tmp/fennec-65.0a1.en-US.android-arm.apk
 0:01.08 [  0%] /data/local/tmp/fennec-65.0a1.en-US.android-arm.apk
   [snip]
 0:01.09 [  5%] /data/local/tmp/fennec-65.0a1.en-US.android-arm.apk
 0:01.09 [  5%] /data/local/tmp/fennec-65.0a1.en-US.android-arm.apk
 0:01.09 adb: error: failed to copy 'dist/fennec-65.0a1.en-US.android-arm.apk' to '/data/local/tmp/fennec-65.0a1.en-US.android-arm.apk': remote Permission denied
 0:01.09 dist/fennec-65.0a1.en-US.android-arm.apk: 0 files pushed. 86.7 MB/s (2555592 bytes in 0.028s)
 0:01.09 /home/botond/dev/mozilla/refactoring/mobile/android/build.mk:42: recipe for target 'install' failed
 0:01.09 make: *** [install] Error 255
 0:01.09 make: Leaving directory '/home/botond/dev/mozilla/out-of-tree-objdirs/refactoring-android-arm'
Another issue that's possibly related, is that I gave to check a permission dialog on the phone every time I run |mach mochitest| after |mach install|. It would be nice not to have to do that, either.
(In reply to Botond Ballo [:botond] from comment #5)
> (In reply to Geoff Brown [:gbrown] from comment #1)
> > How does |mach install| fail? What's the error message/output?
> 
>  0:00.53 /usr/bin/make -C . -j16 -s -w install

...

What does the logcat say?
(In reply to Bob Clary [:bc:] from comment #7)
> (In reply to Botond Ballo [:botond] from comment #5)
> > (In reply to Geoff Brown [:gbrown] from comment #1)
> > > How does |mach install| fail? What's the error message/output?
> > 
> >  0:00.53 /usr/bin/make -C . -j16 -s -w install
> 
> ...
> 
> What does the logcat say?

Only thing I see in the logcat when I run this command is:

10-26 13:06:01.657 11195 11195 W adbd    : type=1400 audit(0.0:51): avc: denied { dac_override } for capability=1 scontext=u:r:adbd:s0 tcontext=u:r:adbd:s0 tclass=capability permissive=0 ppid=1 pcomm="init" tgid=9932 tgcomm="adbd"
Looks root related: permissive=0. 

The make target is just:

install::
	$(ADB) install -r $(DIST)/$(PKG_PATH)$(PKG_BASENAME).apk

was it previously installed via mozdevice which might have used root?
(In reply to Bob Clary [:bc:] from comment #9)
> Looks root related: permissive=0. 
> 
> The make target is just:
> 
> install::
> 	$(ADB) install -r $(DIST)/$(PKG_PATH)$(PKG_BASENAME).apk

I can confirm that running that command directly gives me the same permission error.

> was it previously installed via mozdevice which might have used root?

I'm not sure what mozdevice is; certainly I didn't install my local build any other way than via |mach install| or |adb install|.

Note that I'm currently in root mode when trying to run this command and getting the permission error (I think because |mach mochitest| puts me in root mode). I have to _unroot_ (|adb unroot|) for the command to succeed.
Ok, I think that is it then. the make install uses adb install directly but the mach mochitest does use mozdevice (which is our adb*.py utility for dealing with devices in unit tests) which does turn root when it is initialized. I guess we should check if we used adb root to enable root and then before exiting the test we should adb unroot.
I'm also experiencing an issue with mozregression (bug 1495596 comment 21) that may be related: when I try to run mozregression on Fennec, it puts adb into root mode before installing the apk, and then trying to install the apk fails with the same permission error.
Priority: -- → P3
We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → INCOMPLETE
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.