From david at boddie.org.uk Tue Sep 11 08:29:01 2018 From: david at boddie.org.uk (David Boddie) Date: Tue, 11 Sep 2018 14:29:01 +0200 Subject: [Mobile-sig] Android build changes Message-ID: <1623575.VUjTErx2FD@aurora> I noticed recently that there was some discussion about changes to recent versions of Android that could cause problems for downstream projects. Google requiring API Target 26 in 2018: https://groups.google.com/forum/m/#!topic/kivy-dev/hbufnwBezH0 pybee/general messages: https://gitter.im/pybee/general?at=5b3d4d673d8f71623d5d1cd1 https://gitter.im/pybee/general?at=5b407f8e63042f2df35da1ab Can anyone say what the major issues were? David From russell at keith-magee.com Tue Sep 11 21:35:55 2018 From: russell at keith-magee.com (Russell Keith-Magee) Date: Wed, 12 Sep 2018 09:35:55 +0800 Subject: [Mobile-sig] Android build changes In-Reply-To: <1623575.VUjTErx2FD@aurora> References: <1623575.VUjTErx2FD@aurora> Message-ID: Hi David, The threads you?ve linked are dealing with 2 slightly different problems. The reference to the Kivy mailing list is about the Android API target version. When you build an Android project, you specify a *minimum* SDK version, and a *target* SDK version. The Minimum version specifies which APIs are available; the Target specifies exactly what behavior those APIs will have. For example, consider an API for a new feature foo(). The feature is introduced in API level 20; the behavior is modified slightly (say, to increase security, or change the handling of a default value) in API level 22.? a) If you specify a minimum API of 19, the method foo() won?t be available (no matter the target version). However, you will be able to run your app on really old *and* really new devices. b) If you specify a minimum API of 21, and a target of 21, the method foo() will exist, and will have the ?old? behavior. The app won?t run on *really* old devices, but will run on anything supporting API 21 or newer. c) If you specify a minimum API of 21, and a target of 23, the method foo() will exist, and will have the ?new? behavior. The app will run on the same devices as case (b) d) If you specify a minimum API of 23, and a target of 23, the method foo() will exist, will have the ?new? behavior, and will only run on the most recent devices. The Android blog post that you?ve referenced is about what will be allowed on the Google Play store; they?re setting limits on what you can upload to the Play store based on the *target* API. They?re essentially ensuring that the ?new? behavior for all their APIs is being used (mostly for security reasons), and enforcing that by preventing anyone from (easily) distributing an app that uses old (potentially insecure) behaviours. This isn?t an Android specific thing either - iOS has a similar API versioning policy. The only difference is that iOS?s versions actually match their OS version numbers, rather than the triumvirate of naming that Android uses (Lollipop, V5.0 and API level 21 are all the same thing; Lollipop can also refer to V5.1/API level 22). The references on the BeeWare chat are about Android Studio, the Android build system, and the changes to the Android gradle target. That versioning is (annoyingly) completely independent of the Android API version numbering. Over the last year, the Gradle format has radically changed, and the migration path hasn't been obvious. This is something we (BeeWare) have been wrestling with for about 6 months, but we haven?t had a lot of luck finding people who know both (a) Python and (b) Android who have volunteered to help out. Yours, Russ Magee %-) On 11 September 2018 at 8:29:09 pm, David Boddie (david at boddie.org.uk) wrote: I noticed recently that there was some discussion about changes to recent versions of Android that could cause problems for downstream projects. Google requiring API Target 26 in 2018: https://groups.google.com/forum/m/#!topic/kivy-dev/hbufnwBezH0 pybee/general messages: https://gitter.im/pybee/general?at=5b3d4d673d8f71623d5d1cd1 https://gitter.im/pybee/general?at=5b407f8e63042f2df35da1ab Can anyone say what the major issues were? David _______________________________________________ Mobile-sig mailing list Mobile-sig at python.org https://mail.python.org/mailman/listinfo/mobile-sig -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at boddie.org.uk Wed Sep 12 06:31:36 2018 From: david at boddie.org.uk (David Boddie) Date: Wed, 12 Sep 2018 12:31:36 +0200 Subject: [Mobile-sig] Android build changes In-Reply-To: References: <1623575.VUjTErx2FD@aurora> Message-ID: <9317960.Tpebjgd2r7@aurora> On Wednesday 12. September 2018 09.35.55 Russell Keith-Magee wrote: > The threads you?ve linked are dealing with 2 slightly different problems. Ah, yes. Sorry for conflating the two things. I think I was looking for the build issue in the Kivy list archives and found the API issue instead. Just to clarify something: > b) If you specify a minimum API of 21, and a target of 21, the method foo() > will exist, and will have the ?old? behavior. The app won?t run on *really* > old devices, but will run on anything supporting API 21 or newer. > > c) If you specify a minimum API of 21, and a target of 23, the method foo() > will exist, and will have the ?new? behavior. The app will run on the same > devices as case (b) I'm guessing it will only have the "new" behavior on new devices. Those that only support API level 21 won't be able to implement the later behavior. > The Android blog post that you?ve referenced is about what will be allowed > on the Google Play store; they?re setting limits on what you can upload to > the Play store based on the *target* API. They?re essentially ensuring that > the ?new? behavior for all their APIs is being used (mostly for security > reasons), and enforcing that by preventing anyone from (easily) > distributing an app that uses old (potentially insecure) behaviours. Yes, I ran into an issue like this recently, but not with the Play store, just with running an app written to use an API in an old way on a phone with a newer API. In that case the way you could use the network features had changed to prevent their use in the GUI thread. So changing the target API version to a higher number caused the app to raise an exception. > The references on the BeeWare chat are about Android Studio, the Android > build system, and the changes to the Android gradle target. That versioning > is (annoyingly) completely independent of the Android API version > numbering. Over the last year, the Gradle format has radically changed, and > the migration path hasn't been obvious. This is something we (BeeWare) have > been wrestling with for about 6 months, but we haven?t had a lot of luck > finding people who know both (a) Python and (b) Android who have > volunteered to help out. I'm sure I saw something about this in the Kivy list archive, which is why I went looking in the Beeware Gitter logs. Incidentally, is the Gitter discussion archived anywhere? It's not a lot of fun scrolling back through the messages in a web browser. David From russell at keith-magee.com Wed Sep 12 21:37:39 2018 From: russell at keith-magee.com (Russell Keith-Magee) Date: Thu, 13 Sep 2018 09:37:39 +0800 Subject: [Mobile-sig] Android build changes In-Reply-To: <9317960.Tpebjgd2r7@aurora> References: <1623575.VUjTErx2FD@aurora> <9317960.Tpebjgd2r7@aurora> Message-ID: On 12 September 2018 at 6:31:45 pm, David Boddie (david at boddie.org.uk) wrote: On Wednesday 12. September 2018 09.35.55 Russell Keith-Magee wrote: > The references on the BeeWare chat are about Android Studio, the Android > build system, and the changes to the Android gradle target. That versioning > is (annoyingly) completely independent of the Android API version > numbering. Over the last year, the Gradle format has radically changed, and > the migration path hasn't been obvious. This is something we (BeeWare) have > been wrestling with for about 6 months, but we haven?t had a lot of luck > finding people who know both (a) Python and (b) Android who have > volunteered to help out. I'm sure I saw something about this in the Kivy list archive, which is why I went looking in the Beeware Gitter logs. Incidentally, is the Gitter discussion archived anywhere? It's not a lot of fun scrolling back through the messages in a web browser. Not that I?m aware of; the ?web history? *is* the log AFAICT. Yours, Russ Magee %-) -------------- next part -------------- An HTML attachment was scrubbed... URL: