817235 - Allow remote xpcshell tests to use /mnt/sdcard/tests as test root

Status: RESOLVED FIXED

(Testing :: General, defect)

Description

[Geoff Brown [:gbrown]]

Most (all?) current remote production tests use a "test root" directory of /mnt/sdcard/tests. SUT uses /mnt/sdcard/tests as the test root unless /mnt/sdcard cannot be accessed; ADB uses /data/local/tests only if it already exists, otherwise /mnt/sdcard/tests.

Remote xpcshell tests do not run if /mnt/sdcard/tests is used as the test root only because the xpcshell binary and its xpcw wrapper script require execute file permissions, and execute permissions cannot be set on files under /mnt/sdcard. 

Using /data/local/tests as test root for xpcshell tests is problematic due to storage capacity concerns. Many devices have 100 MB or less of storage free on /data, while /mnt/sdcard is often under-utilized and is relatively easy to expand. The xpcshell binaries, libraries and test files collectively approach 100 MB.

This bug proposed using the devicemanager-supplied test root for all the xpcshell test and support files, placing only the binaries on /data/local.

See also bug 810347, which seeks greater flexibility in the location of the test root.

Comment 1

[Geoff Brown [:gbrown]]

There is already a remoteBinDir in remotexpcshelltests.py; simply changing remoteBinDir = "/data/local/xpcb" has the desired effect. But there is a problem:

If SUT is used, and /data/local/xpcb does not exist, SUT will try to create it, but will (likely) not have the permissions to do so. (devicemanagerADB does not have this limitation.)

Some possible ways forward:

 - make it a precondition of running xpcshell tests that /data/local/xpcb exists and is writable by SUT
 - try to execute something like "su -c mkdir /data/local/xpcb"

Looking for ideas, thoughts....

Comment 3

[William Lachance (:wlach)]

I wonder at what point it makes sense to turn the xpcshell tests into an actual android application (just the minimum required to run tests and report results). How hard would this be relative to all the crazy hacks we need to get these running on the device?

Comment 4

[Geoff Brown [:gbrown]]

That's a thought, but I feel like we are 99% of the way there, and I'm not sure there are that many hacks in the works.

But there is this one issue which puzzles me:

(In reply to Geoff Brown [:gbrown] from comment #1)
> If SUT is used, and /data/local/xpcb does not exist, SUT will try to create
> it, but will (likely) not have the permissions to do so. (devicemanagerADB
> does not have this limitation.)

Using my local tegra, I verified that sut's MKDR command fails when we call dir.mkdirs(), with dir=="/data/local/xpcb". But consider:

# run-as com.mozilla.SUTAgentAndroid
$ mkdir /data/local/xpcb
$ ls -l /data/local
drwxrwxrwx root     app_31                      1970-01-04 15:53 xpcb
drwxrwxrwx shell    shell                       1970-01-04 15:38 tmp
$ rmdir /data/local/xpcb
$ exit
# 

I don't understand why the sut process cannot make the directory, when run-as com.mozilla.SUTAgentAndroid can.

Comment 5

[Geoff Brown [:gbrown]]

Attachment: use /data/local only for xpcshell executables

This patch moves the xpcshell "bin" directory to /data/local, regardless of test root. This way the devicemanager can set the test root to /mnt/sdcard or /data/local (or whatever!), and xpcshell can still be executed. 

I do not know why sut's mkdir fails on /data/local (at least on a tegra), but exec'ing mkdir instead works just fine. 

Tested with both adb and sut on my tegra.

Comment 6

[Joel Maher ( :jmaher ) (UTC -8)]

Comment on attachment 693099 [details] [diff] [review]
use /data/local only for xpcshell executables

Review of attachment 693099 [details] [diff] [review]:
-----------------------------------------------------------------

I can see this being confusing over time, but it is documented and gets us moving forward.

Comment 7

[William Lachance (:wlach)]

(In reply to Geoff Brown [:gbrown] from comment #5)

> I do not know why sut's mkdir fails on /data/local (at least on a tegra),
> but exec'ing mkdir instead works just fine. 
> 
> Tested with both adb and sut on my tegra.

sut's mkdir would be executed as a java call in an unprivileged android application. Maybe calls like that are disallowed outside of various obvious places for security reasons.

Comment 8

[Geoff Brown [:gbrown]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/f9e5c189ae6b

Comment 9

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/f9e5c189ae6b