[Feature request] question: low min and target android version

[rezad1393]

hi. I have installed this app and like it a lot. when I used another app https://f-droid.org/en/packages/com.absinthe.libchecker/ that shows info about apps. one of the few apps that has low minimum and target version is this app. why? why min version for this app is android sdk 10 which is android version 2. and target is android sdk 25 which is android 7.1

[Sunspark-007]

It doesn't need the newer APIs to display dates and times.

That'll change in the future when the 3D-rendered animations come in.

[rezad1393]

It doesn't need the newer APIs to display dates and times.

That'll change in the future when the 3D-rendered animations come in.

sorry I am not familiar with android dev ecosystem that much. I am familiar with linux world. I understand the min part. I don't understand the target part (not just for this app).

[forrestguice]

I try to make an effort to support old, even ancient devices, which its why the minApi is stuck at api10. Meanwhile the targetApi is fixed at api25 because it allows the app to continue using such a low minimum. Unfortunately Google decided to introduce breaking changes in the Android Support Libraries at api26 (calling it "androidx"), and started requiring a minimum of api14. So the targetApi and minApi are actually linked in some ways, and I'm unable to increase one without the other.

Its my intention to drop support for api10 soon though (#122), and to bump the minimum to api14 by the end of the year. I doubt there are any functioning api10 devices left in the wild. Its hard to believe its going on five years since I opened that issue - time flies. After increasing the minApi it will become possible to upgrade the support libraries, and then possible to increase the targetApi (gaining access to features like "Material You"). When all this is eventually done I'll tag it as Suntimes v1.0.0.

Unfortunately there are other reasons for preferring a lower targetApi. It has helped discourage blatant copycats / GPL violations on the PlayStore (#364), as it has become impossible to publish the app there without making modifications (which then must also be published under the GPL). The people who engage in this stuff are looking for "low hanging fruit" and seem discouraged by the (modest) amount of work required to bring the app up-to-date. Afterward, I will probably once again (re)discover malicious copies of Suntimes on PlayStore. So it goes.

[rezad1393]

thanks for the answer. I am from linux world where keeping low version libraries is bad. I thought maybe apps that support low level android do that only for the first reason you posted (so that older device can use the app).

also doesn't setting min version that low, lowers security somewhere in the app? again maybe this is a bad question as I am used to "higher version equals more secure version" in linux world.

when you specify min version as that version and target as that higher, does that mean you have to use a lot of code paths for selecting which code to run on which version ranges or not really ? or asked another way, does your app uses any feature that are only present at ,say, android 6 and later?

after reading some of the post on that issue, #112 I saw that even at that time android 5 was very old.

you say that you only release this app on f-droid. I read here https://privsec.dev/posts/android/f-droid-security-issues/ ( blog of a GrapheneOS developer I think) that f-droid has many issues and one of the issues it reported was https://privsec.dev/posts/android/f-droid-security-issues/#3-low-target-api-level-sdk-for-client--apps that says: "Setting it too low isn’t practical though, because this requires having a lot of fallback code (most of it is handled by common libraries) and separate code paths."

I understood your point that you are stuck at min version 10 as after that there was a change that you didn't want to do, but if you change that later please don't use low target version.

I did not understand the relation between copying your app and target version unless you mean that if you take the app target high then copier can upload them to google play. if that is the case you can you can use a target lower than 33 on august 2023 and this causes it to not be uploadeable to google play. but maybe that take a low effort to cheat so I cant say it forcefully.

At the end I think you can go (at worst) min version api 23 (android 6) or maybe even min version 21 (android 5). I say the api 21 because that is what the majority of my installed apps on my phone use as min version. (according to the the great app LibChecker from fdroid) And I said api 23 because that is literally the lowest that fdroid client newest version can be installed on. https://f-droid.org/en/docs/Running_on_old_Android_versions/

another reason to go for android 6 is that deviced running the next version of android (14) won't install apps targeting lower than android 6 as said here: "Google announced Android 14 on February 8, 2023, with the first Developer Preview releasing on the same day. It will block the installation of old apps based off of older Android SDKs with a plan of requiring an app to be based off of at least the Android 6 SDK. This is done for security purposes as malware targets older Android SDKs in order to circumvent mitigations of protections against such attacks in newer Android SDKs.[308]"

so apps for android under 6 are not even install-able if I read that correctly.

maybe this is the excuse you need to upgrade the versions at last :)

[forrestguice]

I thought I explained the issue pretty well, but I will try to elaborate. Supporting both old and new is a balancing act. Its not something I do because its easier. Its actually quite difficult.

also doesn't setting min version that low, lowers security somewhere in the app

The short answer is "No", but this really depends on the specific APIs. It would be foolish to run an ancient app that requires encryption for example, or otherwise needs the network. However, Suntimes is a clock - I don't believe there is anything inherently unsafe about the APIs its using. There are certainly (UI related) bugs that are fixed in later versions.

when you specify min version as that version and target as that higher, does that mean you have to use a lot of code paths for selecting which code to run on which version ranges or not really ?

Yes. This is a pretty normal occurrence (if this were C++ it would be littered with compiler directives). Every time the API is deprecated for example, or where features are introduced (and not available on earlier versions).

after reading some of the post on that issue, https://github.com/forrestguice/SuntimesWidget/pull/112 I saw that even at that time android 5 was very old.

Yes, the amount of foot dragging is impressive even to me ;) I no longer have any strong reasons for holding it back now.

Setting it too low isn’t practical though, because this requires having a lot of fallback code (most of it is handled by common libraries) and separate code paths."

F-Droid has undergone multiple independent security audits, so I would take what you read there with a grain of salt.

I understood your point that you are stuck at min version 10 as after that there was a change that you didn't want to do, but if you change that later please don't use low target version.

I will choose the targetApi that makes sense given the constraints I am working with. I cannot promise that the targetApi will always be the latest, especially if it means dropping support for old devices. This is definitely what Google would like (as required by PlayStore). It is also the mechanism used to force obsolescence, something I disagree with strongly.

I did not understand the relation between copying your app and target version unless you mean that if you take the app target high then copier can upload them to google play.

There is currently (modest) technical debt that blocks the app from being published to PlayStore. The would-be-copyright-violator, when faced with even a small amount of work, is completely discouraged. Supposing they did that work, they would be required to publish their changes (which would reveal the malicious nature of their fork - typically network permissions and ads). That is something that practically never happens, so in the past I've had Google remove these copycats on this basis (license violation).

if that is the case you can you can use a target lower than 33 on august 2023

This had occurred to me - its possible to maintain the current strategy by keeping the targetApi just below the PlayStore threshold. It would take less effort to "cheat", but it still makes demonstrating unlicensed modifications easier.

The alternative is to match the latest targetApi, and publish binaries to PlayStore myself. If I went that route I would choose to sell binaries ($5) distributed outside of F-Droid. I'm really on the fence about this. I don't miss any of my previous interactions with Google - this is its own form of work.

At the end I think you can go (at worst) min version api 23 (android 6) or maybe even min version 21 (android 5).

Opinions are quite different with regards to these numbers. I still own an ancient tablet running api15 - its used to play video on long trips. I also have an older phone running api19 - phone/network service has been cut off for years, but it still serves a similar function. Suntimes is a clock - imho a clock shouldn't have unreasonable constraints when it comes to minimum version. I want it to be the last app running on your device before you finally choose to recycle it ;)

another reason to go for android 6 is that deviced running the next version of android (14) won't install apps targeting lower than android 6

Right, but as noted Suntimes currently targets Android 7 (api25), so that requirement is already met. I think its relatively easy to confuse minApi and targetApi requirements. The fact that Google warns (or blocks) is a good reason to increment versions though - I believe a nasty warning about "privacy & security" is currently displayed on those devices, and a lot of newer users are being turned away (because they are hesitant to "install anyway".

[rezad1393]

thank you for reading my post. keep in my mind that I am not a developer and just a user that browses the Internet and my suggestions are based on that and my incomplete ideas about security and my (usually retarded) takes from security blog posts.

I agree with most of what you wrote, except the "mechanism used to force obsolescence" part.

I am with you that forcing completely good hardware to be useless and thrown out is one of the most evil things that happens with new age that we live in. that doesn't just applied to phone (software related) but waste in general consumerism. I hate it so much that even though I live in an oil rich county I think if oil wasn't there maybe humans would learn to create stuff that last instead of plastic shit that just pollutes.

having said all of that I think approach by google is not for that. I think this is for lessening fragmentation in support and version and in long run (with help of Treble and other improvements in android) it actually helps older hardware run longer. maybe like and extended iOS model. for example my own phone is no longer supported by xiaomi but I have android 13 on it because of stuff like project treble and generic system images for android that helps with running new versions of android on older devices.

but this is a medium and long term goal and in short term would hurt a bit with very old devices.

still own an ancient tablet running api15

respect.

[forrestguice]

thank you for reading my post.

No problem. I've actually been thinking about this a lot recently. I'm glad to be able to articulate my reasoning, while trying to determine the best course of action.

for example my own phone is no longer supported by xiaomi but I have android 13

I'm a bit jealous. I made some poor purchasing decisions in the past, which is how I ended up with hardware I can't flash. Lessons learned.

[rezad1393]

it is not that old of a phone, at most 5 years old ( mi a2). but I learned from my Samsung 2014 tablet and shit support from Samsung at that time to get a unlock-able phone. also I don't like bloatware so I went for a phone that was from Android One program and was available in my country (Iran).

ironically if google completes project mainline for all the system parts I may not have to get a phone that I have to check xda forums before buying. just need to be able to flash and I can count on someone from india releasing a ROM for it (God bless them). and bloatware is way less now and can be disabled easier.

btw about minimum version, maybe you don't have to consider all the devices that exist for supporting and just see if your users have a device that is relatively not old.

what I mean is that, yes you have a very old tablet but you probably have a phone that is not really that old. so release the app for those. what I mean is that your app may not run on all the devices that your target audience have., but they usually (99% of them) have a device that can run the new version (say min version android 8). in other words they may have ancient devices that if you update the min version to android 6 then they cant install on them but they almost certainly have one device that is not too old and can install it. your users probably don't need that app on all their devices and only need it to run on one device. at least that is my take.

if your app was a music or video player the situation would be different and then your users would probably user them on all their devices.

[rezad1393]

this may help a bit with those pesky stealing devs. https://alternativeto.net/news/2023/7/google-unveils-enhanced-developer-verification-and-blockchain-transparency-policies-for-playstore/

[rezad1393]

https://android-developers.googleblog.com/2023/07/google-play-services-discontinuing-updates-for-kitkat.html so maybe min version can go to android 5.