Closed Bug 788666 Opened 8 years ago Closed 8 years ago
Multiple APK: Each APK must not exactly match the configuration support of another APK
When trying to activate ARMv7 and ARMv6 builds in the Play Store, we hit an error: Each APK must not exactly match the configuration support of another APK It seems that both APKs can not support the exact same configuration, which in our case is: API Level: 8-16+ Supported screens: small-xlarge Open GL Textures: all We will need to tweak one of these three for ARMv6
Only certain filters currently work for Multiple APK support in Google Play: http://developer.android.com/guide/google/play/filters.html#MultiApks http://developer.android.com/guide/google/play/publishing/multiple-apks.html The only supported filters are: * OpenGL texture compression formats * Screen size/density * API level We want our APKs to differ only in the "Native platforms" filter, but the current Multiple APKs support does not allow this. (Instead, we are supposed to include all platforms in one APK, which would bloat our download/install size greatly.)
Whatever solution we find should be tested with a local build on a test Google Play account, to prevent an unnecessary re-spin.
Assignee: nobody → blassey.bugs
Attachment #658598 - Flags: review?(mbrubeck)
Attachment #658598 - Flags: review?(mbrubeck) → review+
When uploading to the test product on the Play Store, we ran into "Google Play does not accept apks signed with the debug certificate. Create a new certificate that is valid for at least 50 years." Could somebody from RelEng help with signing? http://dump.lassey.us/fennec-18.0a1.en-US.android-arm.apk http://dump.lassey.us/fennec-18.0a1.en-US.android-armv6.apk
(In reply to Alex Keybl [:akeybl] from comment #4) > When uploading to the test product on the Play Store, we ran into > > "Google Play does not accept apks signed with the debug certificate. Create > a new certificate that is valid for at least 50 years." > > Could somebody from RelEng help with signing? > > http://dump.lassey.us/fennec-18.0a1.en-US.android-arm.apk > http://dump.lassey.us/fennec-18.0a1.en-US.android-armv6.apk aki's on it.
Brad posted up signed builds and I uploaded them. Sadly, we ran into https://img.skitch.com/20120905-fyp8ksrqa58pmp7ts9r3p3e6ic.jpg. Matt and Brad were still discussing other options in #r-d, but I don't believe that'll make it in the b2 timeframe.
this one actually works in the market
Comment on attachment 658734 [details] [diff] [review] patch Just to be clear, this means that the few ARMv7 devices in the "small" class (e.g. the Droid Pro?) will get the ARMv6 build, which will be a bit larger and slower than the ARMv7 build. This seems like a reasonable trade-off if this is the only workaround available...
Attachment #658734 - Flags: review?(mbrubeck) → review+
Brad found out that the Droid Pro is an HVGA device, and HVGA is considered "medium". We don't really support any "small" screen devices yet.
Droid Pro is HVGA, and to paraphrase the documentation, "small" is less than HVGA. Docs here: http://developer.android.com/guide/topics/manifest/supports-screens-element.html#small > android:smallScreens > Indicates whether the application supports smaller screen form-factors. A small screen is > defined as one with a smaller aspect ratio than the "normal" (traditional HVGA) screen. An > application that does not support small screens will not be available for small screen > devices from external services (such as Google Play), because there is little the platform > can do to make such an application work on a smaller screen. This is "true" by default. I should also note, I thought we had HVGA as our minimum requirement for screen size but could actually find that documented anywhere when I looked for it. I don't know of any ARMv7 devices that fall below HVGA, but there are ARMv6 devices such as the Galaxy Fit. Bug 772286 shows that we don't really support that form factor currently, so we should be sure to block list any ARMv6 devices that are below HVGA.
As for the split-release multiple APK test, results are below of installations on the following (determined from about:buildconfig): * Samsung Galaxy Nexus → ARMv7 * Samsung Galaxy Note → ARMv7 * Asus Transformer Prime TF201 → ARMv7 * Motorola Droid Pro → ARMv7 * Samsung Galaxy Tab 2 → ARMv7 -- * Samsung Gio S5660 → ARMv6 * HTC Legend → ARMv6 * HTC Wildfire S → ARMv6 * LG Optimus S → ARMv6 * LG Optimus Slider → ARMv6 QA does not have a device with an aspect ratio equivalent of meeting the 'smallScreen' attribute and smaller than the aspect ratio of an HVGA device.
OS: Linux → Android
Hardware: x86_64 → ARM
* Galaxy Ace → ARMv6
Comment on attachment 658734 [details] [diff] [review] patch [Approval Request Comment] Bug caused by (feature/regressing bug #): User impact if declined: Testing completed (on m-c, etc.): Risk to taking this patch (and alternatives if risky): String or UUID changes made by this patch:
Pre-approving for aurora/beta based on testing, we'll want to get this uplifted so we can respin 16.0b2
blassey's landing on default of mozilla-beta: http://hg.mozilla.org/releases/mozilla-beta/rev/29f659b8522f Transplanted to MOBILE160_2012090412_RELBRANCH for 16.0b2 build2: http://hg.mozilla.org/releases/mozilla-beta/rev/b7daf566e84a
I unpublished the split release test apk, since release@ got an email saying "Hi Mozilla, SplitReleaseTest for Android was just added on FileDir.com"
mbrubeck's is on Google Play too. Matt, did you want to unpublish it?
(In reply to Aaron Train [:aaronmt] from comment #19) > mbrubeck's is on Google Play too. Matt, did you want to unpublish it? Unpublished.
(In reply to Brad Lassey [:blassey] from comment #11) > Bug 772286 shows that we don't > really support that form factor currently, so we should be sure to block > list any ARMv6 devices that are below HVGA. I don't believe we have any 800MHz/512MB RAM phones that are below HVGA. Before lowering the CPU specs in 17, we'll have to recheck. Filed bug 789453.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 18
Justin@ORION /d/sources/mozilla-aurora $ hg transplant -s http://hg.mozilla.org/mozilla-central d627e554fff4 searching for changes applying d627e554fff4 patching file mobile/android/base/AndroidManifest.xml.in Hunk #1 FAILED at 8 1 out of 1 hunks FAILED -- saving rejects to file mobile/android/base/AndroidManifest.xml.in.rej patching file mobile/android/base/Makefile.in Hunk #1 FAILED at 216 1 out of 1 hunks FAILED -- saving rejects to file mobile/android/base/Makefile.in.rej patch failed to apply abort: Fix up the merge and run hg transplant --continue Also tried transplanting the beta push Justin@ORION /d/sources/mozilla-aurora $ hg transplant -s ssh://hg.mozilla.org/releases/mozilla-beta 29f659b8522f searching for changes applying 29f659b8522f patching file mobile/android/base/AndroidManifest.xml.in Hunk #1 FAILED at 8 1 out of 1 hunks FAILED -- saving rejects to file mobile/android/base/AndroidManifest.xml.in.rej patching file mobile/android/base/Makefile.in Hunk #1 FAILED at 191 1 out of 1 hunks FAILED -- saving rejects to file mobile/android/base/Makefile.in.rej patch failed to apply abort: Fix up the merge and run hg transplant --continue
This fix should no longer be needed because changes to Google Play make things "just work"; see bug 791267 for details. No action required for 17.0 beta.
You need to log in before you can comment on or make changes to this bug.