Feature/bump min target sdk

[SnowVolf]

Phase 1:

• Removed obsolete sdk checks
• bumped min to 28, target 33

[SnowVolf]

@TrianguloY next phase: SAF support. Maybe this weekend

[SnowVolf]

As of I don't have access to this repository, I cannot edit "reviewers" section

[SnowVolf]

@TrianguloY What about the min SDK? I believe that the application should support Android 9.0 at minimum (released 5 years ago). This can keep code base with minimum amount of legacy code

[TrianguloY]

This change is where I'm most concerned with, let me explain:

LL has always been a 'fast launcher' for low-end devices, even if latest versions had a lot of 'advanced' features.

According to Android Studio, sdk 28 (android 9) runs on 84.1% devices, which leaves a 15.9% of devices out.

The current LL community will probably be glad to still be able to use LL in older devices, if this doesn't mean to leave out features and updates.

Basically: I'm not opposing to increasing the sdk, but I would like to have a valid technical reason to do so, if possible. Was sdk 28 chosen because it fails on sdk 27 or just as a '80%' rule? Will the app still work if the target sdk is increased to 33, but the minsdk is kept at 14 (for the time being) or increased to 19?

[SnowVolf]

@TrianguloY Let's start with the fact that the data is relevant on may 30, 2023. I understand that the ability to maintain the most important number of devices is a natural desire. But objectively, the number of old devices will only decrease. Yes, in general, you can add API 26+ support, increasing the number of devices by 5-7%. But adding devices below - it makes no sense in the future.

since the application is written in Java, we do not have the opportunity to use the latest features of the language, as in Kotlin. For example, full support for java 8 was added only in API 26 (java streams)

[TrianguloY]

I understand that.

I'm still not convinced about increasing the sdk just because. If you check my other apps you will see that I try to support very old devices, even if it means not being able to use some of the latest features (which I know are nice to have, but they don't provide any value to a final user). I also dislike Kotlin (even though I really love the language) because it makes apps very bloated, but that's more debatable.

Question: Since right now the app is just being cleaned up, is it possible to keep the min sdk as-is, and don't remove any check, and only when new development is made (and it justifies the newer sdk) increase it? In other words: can you make it so that:

• commit/pr: increase target sdk and make required changes, but don't touch the min sdk.
• commit/pr: Enhancement/code style with Android Studio code style
• other non-feature changes
• commit/pr: increase min sdk
• other feature changes

If you don't agree, and you still think the min sdk should be increased, then...I'll still accept the pr. I value keeping LL alive more than supporting older devices, but I just want you to consider it.

[SnowVolf]

Okay. minsdk downgraded to 26. Some checks reverted, but is quite minimal effort. Oreo is the best compromise

[TrianguloY]

Ok.

I'm still sad that old devices are now unsupported without apparent reason, but as you said Oreo is a good compromise.

Remember that I'm not opposed to increasing it further if the benefits are noticeable. I'll check now the next pr.

Thanks for all your effort! Merged.