Interesting conundrum. The max is for two reasons; one weak and one strong.
The weak reason is to make it easy to have non-overlapping APKs on Play. If the supported API ranges don't overlap, there's less chance of a device installing the wrong one. (Apparently only Play respects maxSdkVersion, given Bug 1117108…) In theory you could 'layer' APKs using minSdkVersion and higher version codes, so that a device would climb the version number ladder as far as its SDK version would allow. We've had version number issues (due to human error) in the past. We might opt to do that; we have six weeks to figure out our Play approach on Aurora. To address the "what if the device upgrades and Play uninstalls your app?!" angle: what should Play do if on upgrading there's an APK that's better suited or matches a different facet other than maxSdkVersion? I'm less concerned than others about this capability going away, because Play has to handle this anyway. This would be easy to test, though. My theory is that you'd upgrade, the app would still be installed, and Play would show you an available update to install the correct APK. (The installed version might crash, but hey.) The docs around maxSdkVersion processing all talk about "preparing to install your app". Nothing at all about later stages of the lifecycle. The strong reason is that the range-limited APK might not work on higher API versions at all. We strip resources, simplify conditionals, plan to exclude libraries (Bug 1063873), and we don't test the numerous unexpected combinations — the APK really does have a max API version. If we must allow an APK to continue to work when you upgrade from, say, API 9 to API 14, then many avenues are closed to us: we can't strip non-Gingerbread versions of libraries, we can't exclude compat code for ICS, etc. etc. That's a big change from where we are now, and we lose a lot of benefit — we can only exclude stuff that's invariant, like screen dpi. We couldn't even exclude tablet stuff without producing two Gingerbread APKs, one with tablet resources and one without, just in case you upgrade your Gingerbread tablet-sized device to modern Android! This becomes ridiculous enough that I think it supports my theory above. Some research indicates that we can use variant.processManifest.doLast to mutate the AndroidManifest file on disk after Gradle's done with it, and do so on a per-variant basis. This works around Gradle's limitations. The two avenues I think are worth pursuing: - In the course of preparing for Google Playifying our split APKs, we should be testing the device upgrade path, and determining whether we need to switch to tiered version numbers. - If that's safe, then we should add a Gradle build stage to mutate the manifest to keep maxSdkVersion. On Sun, Jan 11, 2015 at 4:21 PM, Nicholas Alexander <[email protected]> wrote: > Hi all, but mostly rnewman, > > I discovered that maxSdkVersion is not supported by Gradle. One possible > reason is given at [1]. I wanted to make sure rnewman was aware of this, > but then thought I'd surface this more widely to ask what we use the max > for, and to solicit feedback on whether we should/shouldn't be using it. > If you have data/anecdotes/opinion, please respond. > > Yours, > Nick > > [1] http://stackoverflow.com/a/25007569 > > _______________________________________________ > mobile-firefox-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/mobile-firefox-dev > >
_______________________________________________ mobile-firefox-dev mailing list [email protected] https://mail.mozilla.org/listinfo/mobile-firefox-dev
