Skip to content
This repository has been archived by the owner on Jun 1, 2023. It is now read-only.

Bump minSdkVersion to 21 (lollipop) #368

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Bump minSdkVersion to 21 (lollipop) #368

wants to merge 1 commit into from

Conversation

ghost
Copy link

@ghost ghost commented Jan 6, 2017

As by https://forum.xda-developers.com/showthread.php?t=3034811 this version is only suited for api-21 and above, this should be respected in the minSdkVersion.

As by https://forum.xda-developers.com/showthread.php?t=3034811 this version is only suited for api-21 and above, this should be respected in the minSdkVersion.
@rovo89
Copy link
Owner

rovo89 commented Jan 6, 2017

I think the idea is right, but I wouldn't want to close the door for adding support for earlier Android versions one day. If the minSdkVersion is 21, new code might not be compatible with 15 anymore.

@ghost
Copy link
Author

ghost commented Jan 6, 2017

Looking at the docs, the only intended purpose of this, is user-facing:

An integer designating the minimum API Level required for the application to run. The Android system will prevent the user from installing the application if the system's API Level is lower than the value specified in this attribute. You should always declare this attribute.

https://developer.android.com/guide/topics/manifest/uses-sdk-element.html

If an IDE like AS provides some automated checks against this value, that might be cover by adding minSdkVersion at multiple locations, e.g. having debug builds with lower requirements than release builds. Would that be acceptable?

@rovo89
Copy link
Owner

rovo89 commented Jan 6, 2017

If an IDE like AS provides some automated checks against this value

Yep, that's what I was thinking about. If you try to use some SDK21+ method, Android Studio / Lint will show it as an error if the minSdkVersion is lower than that.

e.g. having debug builds with lower requirements than release builds. Would that be acceptable?

Yeah, if that works, it would be fine. Although there's something I don't like about the minSdkVersion: If an APK is rejected because of it, the error message is something like "package is corrupted", no word about the real reason. Maybe it would be better to let the user install the app, but then say that KitKat and below is currently not supported?

@ghost
Copy link
Author

ghost commented Jan 6, 2017

Well, this wouldn't hurt. However, I work on F-Droid and F-Droid honors this setting and doesnt even show such apps for installation (if not expert settings are set to ignore this). I can forcefully up the minsdk at build-time. Or maybe just providing a build flavor for us like...

android {
  ..
    productFlavors { 
         fdroid {
                minSdkVersion 21
         }
    }
}

... would be acceptable?

@Bubu
Copy link

Bubu commented Apr 4, 2018

Taking this over on the f-droid side. As the app itself works on api 15 (just tested) I think there is no reason to have an artificial minapi 21 in the apk/fdroid.

This can be closed form my/our side.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants