ge0rg
commented
2 years ago I've usually followed the policy of not updating the SDK level without a very pressing need. While only 0.6% of the installed base on Google Play is <4.4, and 1% is on 4.4, this is not the full picture. I know from past support requests that a number of amateurs are using old Chinese android tablets, often running 4.x, for APRS.
I'm already using some newer APIs in the app, like for obtaining the NMEA sentences, and for some Bluetooth features, that are broken or unsupported on 4.x, and I won't sleep bad if we don't have testing all the way down to the minimum.
That said, it would probably a good idea to keep it as is for the 1.x branch (or maybe 1.6.x), and increase it with the next larger increment, to give legacy device owners an indication of which last release to download.
Initially I planned to do a significant UI revamp for 2.0, based on Material design, and would have bumped the SDK level for that most probably, but the whole revamp got delayed significantly now due to other obligations.
penguin359
Is it time to bump the minimum API level for APRSdroid or should we continue to support API level 14 for the original KitKat release?
I say this both because of issues I discovered from my own, simple Android app and from my research info getting this app fully tested.
While I had dreams of having my own, personal, and quite simple Android app supporting all the way back to KitKat and beyond, I discovered how difficult that really was. For one, I occasionally called functions that didn't exist on earlier APIs. I had also used third-party libraries like Apache's HttpClient which used to be bundled with Android and discovered it caused conflicts when the app was loaded on older APIs. Overall, I discovered that if you can't easily test that API, you can't really say you support it.
The current minimum API level set in the build is API 14, however, the CI build for GitHub can only test down to API 15 due to the list of available system images provided via sdkmanager. The one API 14 image is 32-bit ARM only which GitHub does not support and also lacks the Google APIs. Even with my testing on API 15, I find that the tests sometimes trigger SecurityExceptions due to INJECT_EVENTS permissions lacking, though, I might have a fix for that.
Then, while researching how to save screenshots from the emulator environment when there's a failure, I ran across the UIAutomator which is a better approach for certain types of UI testing especially with things like Google Maps, however, this library has a minimum requirement for API level 18 which means that any testing it does has to be disabled on API 15 negating it's benefits for vetting old API levels.
One more example of something I ran into with my personal app, AMSAT Status, support for TLS 1.2. As most web servers these days only will talk TLS 1.2 or newer, it was a big deal. I verified that the APRS 2 server ssl.aprs2.net:24580 is included in that list. Until I had added tests to my app's test suite which actually talk to the AMSAT server, I did not realize it was an issue on API 19 that I was testing on. I had to modify my app to enable it. And, even in that case, it won't fix API 14 or 15 that is lacking it.
Now, I realize that TLS support is not critical for basic operation of APRSdroid, but it does mean it may experience reduces features or crashes on older APIs and it can be hard to handle testing on them. This can even be worked around easily enough by including a third-party SSL library instead of using the system SSL support if really desired. Also, I don't know if there's a big difference to allowing them to install the app and just giving them a caveat that it might not fully work vs disallowing it entirely, but something to talk about.