The Android API level determines how location permissions are handled and it is no longer sufficient just to declare these in the Android manifest. I implemented additional dynamic checks on location permissions with an explanation to the user why these are needed and tested these changes on a number of emulators and physicals across a number of API levels.
This threw up a bug in the Oreo emulator which I initially thought was me. The system UI would crash whenever the user was shown the Allow/Deny location permission dialog.
It took me a while to track this down on StackOverflow and for now I’ll be avoiding testing runtime on Oreo, which is a risk, but I can’t really do anything until a fix is rolled out it seems.
For light relief I did a little bit more work on how I should be doing marketing during development and trying to get a feel for what I should be doing regarding initial launch.
On the Strava side, I have to do some jiggery pockery to get OAuth2 playing nice with Android within the runtime app and though the Email/Password and Google authorisation flows seem to work okay for runtime, facebook authorisation is not proven yet and needs to be completed.
This is not helped by the fact that I now have to support three authorisation flow mechanisms for Nougat, Marshmallow and “other” Android flavours. It is very frustrating.
On the upside (ish), I met up with some friends for beers and they dug out and played “Your word against mine” with each other, but, highlighting the great frustration that probably all independent developers have; the lack of feedback from users; they managed to find a multiplayer bug which can incorrectly decide the outcome of a game.
The lack of an un-install hook that would allow a user to leave some comment or feedback from Android users on the Play Store is very frustrating and it is depressing to have to wait until over a year after multiplayer was launched to find a bug like that and for it to be found in front of your eyes.
Due to the complexities of testing the multiplayer mode with Google Play Services on physical devices, I’ve not yet been able to recreate this bug to work on it. It’s high on the “to do” list!
Finally the week ended with more frustration over Android AVDs and the support for Android’s many screen formats. In contrast to the much simpler world of Apple devices, due to the open source nature of Android at the time of writing there are at least 15026 (17th January 2018) different Android devices potentially to support (15001 a few days ago in the Google device catalogue), from a variety of manufacturers.
Android has 4 general screen sizes,
any number of physical screen sizes, 14 different screen densities
and currently API levels 10 through 27 potentially can be supported.
The runtime app explicitly supports API levels 18 through 26 and I
will probably have to do some additional filtration as behavioural
results come in after launch.
The Google Play Analytics app gives a
nice pretty overview of which devices users are using, but it is
really of limited help. What the developer needs is the ability to
either download or easily create an AVD which matches the
specifications of the users device so we can test as closely as
possible to the real thing. Sadly this is not available and I’m
really not sure why it not straightforward for Google or someone to
provide this. It is certainly a service I would be interested in if
it could accurately generate an AVD.
Unfortunately you cannot generate an
AVD which matches particular density, width, height and size
characteristics. Android Studio lumps these into the standard
densities (but not all of them) and certainly not all that the users
are actually using. So I cannot match the user's device to an AVD and
therefore I don’t know how my app is rendering on their device
which is a risk. I’m flying blind.
Apparently there used to be a
capability to specify the display density from the command line when
using the emulator, but this feature has been deprecated for some
reason. More frustration.
Next week will be better, right?
