843821 - Support reading distribution resources from a /system location

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Mark Finkle (:mfinkle) (use needinfo?)]

In order to better support OEMs that bundle Firefox on the ROM, we want to store the customization/distribution resources in a location that is protected from deletion or removal-via-updates.

Brad and I have been looking at various shipping devices and resources online about Android's file system layout. It seems like the /system folder is used as a readonly location for storing bundled APKs. We have also seen vendors (like Motorola, HTC and Samsung) store customization resources in the /system folder.

Therefore we propose to use this location for distribution resources: /system/org.mozilla.firefox/distribution

Where "org.mozilla.firefox" would match the Firefox APK packagename.

This means each channel would look in a slightly different place for distribution files. We don't see this as a problem since we only ever expect "org.mozilla.firefox" to be used and only the release version of Firefox would use the resources.

This also means that Firefox Beta could be installed on the device and it would NOT use the distribution resources meant for "org.mozilla.firefox" (Firefox Release).

The general rules for looking for distribution resources would be:
1. Look in APK and extract resources to /data/data/org.mozilla.xxx/distribution folder
2. Use resources in the /data/data/org.mozilla.xxx/distribution folder if it exists
3. Use resources in the /system/org.mozilla.xxx/distribution folder if it exists

Snorp mentioned a way to manually add files to the /system folder, in order to test the code.

Comment 1

[:Margaret Leibovic]

Since we send "Distribution:Set" based on the SharedPreferences value, I feel like it would make more sense to just tweak the logic in copyFiles() to look in /system if if doesn't find anything in the APK. This would mean the files would still get copied over to /data and used from there, but I don't think that really matters, since this ROM solution is to address concerns that the APK might be overwritten before first run, right?

Otherwise, I feel like a patch for this will need to introduce a lot more new logic.

Comment 2

[:Margaret Leibovic]

Or, we could have a new STATE_SYSTEM or something like that if we see the files in the /system location, and then pass that info along to gecko so that browser.js looks in there for the files.

Comment 3

[:Margaret Leibovic]

(In reply to Mark Finkle (:mfinkle) from comment #0)

> Snorp mentioned a way to manually add files to the /system folder, in order
> to test the code.

snorp, how do I do this?

Comment 4

[:Margaret Leibovic]

Attachment: patch

This patch lets Java still be in charge of telling Gecko when (and now where) to set up distribution stuff.

If we ever want to pave over a system distribution with one in the APK we'll still have to add some way to reset these prefs, but we'll have to do that anyway if we ever want to support changing distributions.

Comment 5

[James Willcox (:snorp) ([e-mail]) (he/him)]

(In reply to :Margaret Leibovic from comment #3)
> (In reply to Mark Finkle (:mfinkle) from comment #0)
> 
> > Snorp mentioned a way to manually add files to the /system folder, in order
> > to test the code.
> 
> snorp, how do I do this?

You need a rooted device. It's easy-ish to root a Nexus device if you need to.

After that you can just run 'mount -o remount,rw /system' as root in adb shell.

Comment 6

[Mark Finkle (:mfinkle) (use needinfo?)]

Comment on attachment 716851 [details] [diff] [review]
patch

Very nice and clean. Since bookmarks uses Distribution.java to access the default bookmarks, this should handle all scenarios.

Let's see if you can test this locally using snorp's hint

Comment 7

[:Margaret Leibovic]

Comment on attachment 716851 [details] [diff] [review]
patch

I put distribution files at /system/org.mozilla.fennec_leibovic/distribution, and this used them successfully!

I also tested with a distribution folder in the APK, and it preferred using that over the distribution folder in /system.

I mentioned this on IRC, but this will require a follow-up for bookmarks to also get pulled out of a /system location, but that doesn't stop us from landing this.

Comment 8

[:Margaret Leibovic]

https://hg.mozilla.org/integration/mozilla-inbound/rev/3c11909c216a

Comment 9

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/3c11909c216a

Comment 10

[:Margaret Leibovic]

Comment on attachment 716851 [details] [diff] [review]
patch

[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 834681
User impact if declined: no distribution support (we want to uplift this so that partners can use it sooner rather than later)
Testing completed (on m-c, etc.): just landed on m-c
Risk to taking this patch (and alternatives if risky): low-risk, this code is pretty self-contained (it will only affect builds using distribution customizations)
String or UUID changes made by this patch: n/a

Comment 11

[Alex Keybl [:akeybl]]

(In reply to :Margaret Leibovic from comment #10)
> User impact if declined: no distribution support (we want to uplift this so
> that partners can use it sooner rather than later)

Do you have any more context around distribution support in the FF20 timeframe? If necessary, we'll definitely approve once this has been in a nightly.

Comment 12

[:Margaret Leibovic]

Oops, noticed I accidentally left some logging in. Got rid of that:
https://hg.mozilla.org/integration/mozilla-inbound/rev/b2c38a3b59dc

Comment 13

[:Margaret Leibovic]

https://hg.mozilla.org/releases/mozilla-beta/rev/bdba94d329cb

There was a merge conflict on aurora, so I want to build to make sure it's all good before I push (I built and tested beta to verify a good merge).

Comment 14

[:Margaret Leibovic]

https://hg.mozilla.org/releases/mozilla-aurora/rev/a9ce9efea742

Comment 15

[Ed Morley [:emorley]]

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

Comment 16

[:Margaret Leibovic]

https://hg.mozilla.org/releases/mozilla-release/rev/3fabe2e026b0

Comment 17

[Aaron Train [:aaronmt]]

Kevin, can you verify this one?

Comment 18

[Kevin Brosnan [Ex-Mozilla]]

We can verify on a device other than the vendor hardware. I think Mozilla China or Taiwan has access to the devices. Might prefer a verification on such hardware.

Comment 19

[Yousheng Li [:yli]]

(In reply to Kevin Brosnan [:kbrosnan] from comment #18)
> We can verify on a device other than the vendor hardware. I think Mozilla
> China or Taiwan has access to the devices. Might prefer a verification on
> such hardware.

Hi Kevin, we tested some devices on Beijing and Taipei office, it works fine on 19.0.2. The testing devices are:
Series 1(SmartPhone Google Nexus One)
CPU：Qualcomm QSD8250 1GMHz
SIM：DSDA W+G
Dimension：119 x 59.8 x 11.5 mm
Memory：512M ROM+ 512M RAM
Display：3.7”
OS：Android 2.3.7

Series 2(Pad: Galaxy Tab GT-P7510)
CPU：Nvidia Tegra 2 
Dimension：256.7 x 175.3 x 8.6 mm
Memory：16G ROM+ 1G DDRII RAM
Display：10.1"
OS：Android 3.1
Launch time：2011/June

Series 3(Pad: Google Nexus 7)
CPU：Nvidia Tegra 3 1.3GHz 
Dimension：198.5 x 120 x 10.45 mm
Memory：8G ROM+ 1G RAM
Display：7"
OS：Android 4.2.2
Launch time：2012/Q4

Series 4(Pad: ASUS Transformer Pad TF300T)
CPU：Nvidia Tegra 3 
Dimension：263 x 180.8 x 9.9 mm
Memory：32G ROM+ 1G RAM
Display：10.1"
OS：Android 4.1.1
Launch time：2012/Q4

The Gigabyte tested on their hardware, too. All of the devices are worked fine.

Comment 20

[Kevin Brosnan [Ex-Mozilla]]

Confirms what I have seen using my HTC G2. Going to call this verified across channels.