Closed Bug 760740 Opened 12 years ago Closed 12 years ago

Use compatible-screens instead of supports-screens to control market filtering of split XUL/Native builds

Categories

(Firefox for Android Graveyard :: General, defect)

All
Android
defect
Not set
normal

Tracking

(firefox14 verified)

VERIFIED FIXED
Firefox 15
Tracking Status
firefox14 --- verified

People

(Reporter: mbrubeck, Assigned: mbrubeck)

References

Details

(Whiteboard: [no-code])

Attachments

(1 file)

Aaron pointed out on IRC that using <compatible-screens> instead of <supports-screens> in AndroidManifest.xml might be a better way to serve the correct version to different devices through the Google Play store:
http://developer.android.com/guide/practices/screens-distribution.html

If I understand the documentation right, <compatible-screens> has the following advantages:

1. It's used only for filtering in the store; it would not prevent non-store installs (so it could not break our test automation like supports-screens did).

2. It can mark an app as tablet-only *or* handheld-only (unlike supports-screens which can only mark an app as tablet-only.)

This would let us update one of the APKs of our split builds without updating the other, since we no longer face the limitation mentioned in bug 721551 comment 5.  It would also let us exclude tablets (bug 759445) without manually finding and blocking every separate tablet model.
Really, this seems like the proper way to do target distribution over the blocking non-sense currently going on.
Setting blocking just to get this on the radar.
blocking-fennec1.0: --- → ?
Attached patch patchSplinter Review
Tested this in my Google Play account and it works.  If we do this, we will no longer need to respin XUL when we update Native, nor will we need to build release builds with different config options from dep/nightly builds.  Nice find, Aaron!
Attachment #629837 - Flags: review?(blassey.bugs)
Status: NEW → ASSIGNED
This definitely sounds like a better option than excluding devices. I can't think of any downsides. Let's test this on with the beta population once we've had XF14 (tablet security update) on the store for about a week. That'll be ~6/15.

In the meantime, let's perform testing around the test product Matt put up.
Keywords: qawanted
Actually, I can't think of a reason to wait - this should also work for our upcoming beta. This'll lock both FN into phones and XF into tablets, correct? So on 6/15 we would just disable the XF APK.
Comment on attachment 629837 [details] [diff] [review]
patch

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

r=blassey under the assumption to that you'll test to make sure we can still install apk's over adb for configurations that aren't supported in the manifest
Attachment #629837 - Flags: review?(blassey.bugs) → review+
(In reply to Alex Keybl [:akeybl] from comment #5)
> This'll lock both FN into phones and XF into tablets,
> correct? So on 6/15 we would just disable the XF APK.

Correct.

(In reply to Brad Lassey [:blassey] from comment #6)
> r=blassey under the assumption to that you'll test to make sure we can still
> install apk's over adb for configurations that aren't supported in the
> manifest

Yes, I verified this with adb installs.

https://hg.mozilla.org/mozilla-central/rev/844ed9db0464
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 15
Comment on attachment 629837 [details] [diff] [review]
patch

Requesting Aurora and Beta approval because this is needed on Fx14 (which moves from mozilla-aurora to mozilla-beta today).

[Approval Request Comment]
User impact if declined:  Without this patch it is more difficult to target specific device classes in Google Play, leading to increased respins/updates for XUL users, and risk of some devices receiving the wrong build.

Testing completed (on m-c, etc.): Landed on m-c today.  This can only really be tested in the Android store.  I tested with local builds in my personal Google Play account.  QA can test this for real once it is in a beta release, just has they have done for all our split builds up to now.

Risk to taking this patch (and alternatives if risky): Mobile-only patch.  This is low-risk; the main area to test is that different devices still receive the correct build in the Play Store.

String or UUID changes made by this patch: None.
Attachment #629837 - Flags: approval-mozilla-beta?
Attachment #629837 - Flags: approval-mozilla-aurora?
Comment on attachment 629837 [details] [diff] [review]
patch

This didn't make the merge, so it's already on aurora (15) and approving to beta (14) please go ahead and land once the trees reopen.
Attachment #629837 - Flags: approval-mozilla-beta?
Attachment #629837 - Flags: approval-mozilla-beta+
Attachment #629837 - Flags: approval-mozilla-aurora?
Attachment #629837 - Flags: approval-mozilla-aurora-
blocking-fennec1.0: ? → betaN+
We verified this with bug 762699
Status: RESOLVED → VERIFIED
Keywords: qawanted
(In reply to Matt Brubeck (:mbrubeck) from comment #11)
> https://hg.mozilla.org/releases/mozilla-beta/rev/1c82c3a258af

In order to disable tablets at release of FN14.0, do we need this change in a re-spin of XF10.0.5 to post to the store disabled?
blocking-fennec1.0: betaN+ → ?
Whiteboard: [no-code]
No, you can disable tablets on the release channel simply by publishing FN14 and removing/disabling any XUL Fennec APKs.  No change to esr10 would be needed.

(I hope we're not planning on disabling tablets on the release channel, though!  I think better communication about our schedule would be much better for our tablet users than simply not allowing them to install Firefox.)
(In reply to Matt Brubeck (:mbrubeck) from comment #14)
> No, you can disable tablets on the release channel simply by publishing FN14
> and removing/disabling any XUL Fennec APKs.  No change to esr10 would be
> needed.

Thanks - given that, unsetting flags.
blocking-fennec1.0: ? → ---
Blocks: 768613
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.