Badge request: supported Android version

[ghost]

📋 Description

Similar to the python badge, I would propose adding support for the following Android badges:

• Android version >= (number)
• Android version >= (name)

Please note: ranges will be dealt with in a separate issue.

🔗 Data

Data has to be gathered from a build.gradle file (example):

android {
    compileSdkVersion 28
    buildToolsVersion '28.0.2'

    defaultConfig {
        applicationId "de.clemensbartz.android.launcher"
        minSdkVersion 17
        targetSdkVersion 28
        maxSdkVersion 28
        versionCode 12
        versionName "1.5"
    }
    buildTypes {
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
    }
}

This has the following challenges:

• module may not be named "app" (see example above), specification necessary
• module may have constants from root to get the version from (e. g. child -> root)

build.gradle is the only place to define it, since when you define the constants outside, you get the following errors (this holds true for Android Studio 3.2 and Gradle 28.0.2):

• minSdk: The minSdk version should not be declared in the android manifest file. You can move the version from the manifest to the defaultConfig in the build.gradle file.

I would also be able to do the implementation.

[chris48s]

👍 Sounds like you've already thought this through quite well.

I would also be able to do the implementation

Excellent. We welcome PRs from new contributors. We've got a tutorial on adding new badges that you can follow: https://github.com/badges/shields/blob/master/doc/TUTORIAL.md

This has the following challenges:

module may not be named "app" (see example above), specification necessary
module may have constants from root to get the version from (e. g. child -> root)

It seems like the best idea here would be to make the path to the build.gradle file a URL param so it is up to the user to pass in the correct path. In fact, if we pass the full link in the URL, that would allow us to support projects hosted on GitLab, BitBucket, etc as well. We do this for a few other badges e.g: JIRA, Jenkins CI e.g:

https://img.shields.io/jira/issue/https/issues.apache.org/jira/KAFKA-2896.svg
https://img.shields.io/jenkins/s/https/jenkins.qa.ubuntu.com/view/Precise/view/All%20Precise/job/precise-desktop-amd64_default.svg

How does that sound?

Data has to be gathered from a build.gradle file

This is fine, but the structure will need to be a bit different from most of our other badges. Most of our service classes inherit from BaseJsonService or BaseXmlService but the .gradle file is neither of those formats. What you'll need to do is create a service class which inherits directly from BaseService and find a package for parsing that format in javascript. The F-Droid badge might be a good example to crib from because that also doesn't use BaseJsonService or BaseXmlService as the parent class: https://github.com/badges/shields/blob/master/services/f-droid/f-droid.service.js

[ghost]

Thank you for the update. Your explanations sound reasonable from a technical standpoint. I will take a look on how to implement that (not a native JavaScript developer though).

[profgrammer]

These npm libraries would help to achieve the following tasks:

• Parse gradle into JSON: https://www.npmjs.com/package/gradle-to-js
• Android version number to version name: https://www.npmjs.com/package/android-versions/v/1.0.1

This looks interesting, I'd like to take this up soon

[PyvesB]

The comment from @chris48s seems a little outdated, use with care. :) I'll share a few thoughts of my own to help design the work.

We've got a lot of similar badges that integrate with dependency management tools, for example version-controlled package.json files (https://github.com/badges/shields/blob/master/services/github/github-package-json.service.js). However, they extend ConditionalGithubAuthV3Service. If I remember correctly, this means that:

• the badge can get private repository files for self-hosted Shields instances using authentication, which is a nice to have.
• the badge will not authenticate on our main Shield.io instance.

Not authenticating for the badges being served by Shields.io is actually super valuable in this case: getting raw files from GitHub is not rate-limited!

Being able to support other use cases than GitHub would be nice. However, if we wanted to deviate from ConditionalGithubAuthV3Service and point to any random file on the Internet as suggested previously:

• we would lose the ability for self-hosted instances to use it with private GitHub repositories, which isn't ideal.
• we may end up with rate-limiting issues with non-GitHub locations, which would make the badge not very useful. In particular GitLab may be an issue here.

@badges/shields-maintainers am I making sense here, and do you have any shine any more light on this matter?

[chris48s]

Yeah that comment is from a long time ago. If we're going to allow an explicit URL to be passed we do it in the query param now

i.e:
https://img.shields.io/jira/issue/KAFKA-2896.svg?baseUrl=https%3A%2F%2Fissues.apache.org%2Fjira
rather than
https://img.shields.io/jira/issue/https/issues.apache.org/jira/KAFKA-2896.svg

A few thoughts (which don't completely provide an answer)

• We do have a bunch of badges following the "get a file from a known location in a github repo and extract a value" pattern that use the ConditionalGithubAuthV3Service base class. I'm starting to wonder if this is a bit of an anti-pattern though and maybe they should all be service-agnostic? See related discussion in issue: move osslifecycle and nycrc into /github #5343
• It is possible to generate a raw.githubusercontent.com URL for files in private repos that uses a token param
• I don't think gitlab rate limits requests to /-/raw, but I'm not 100% sure on that

I think either approach is valid tbh. I guess if we use ConditionalGithubAuthV3Service and make it /github/build-gradle it is in line with /github/manifest-json, /github/go-mod, /github/package-json etc and it is an easier contribution because it follows an established pattern. If we decide to make them all platform agnostic at some point we can turn them into redirects as a block of work as they will all follow the same convention.

btw @profgrammer I notice you've had a few PRs merged recently and this is another issue you're looking into. Thanks for your work on the project 👍 If you want any help as you get into things feel free to join our discord https://discord.gg/HjJCwm5 and ask questions.

[profgrammer]

@chris48s thanks for your inputs. I think it would be a good starting step to first add support for gradle files from GitHub repositories, and as you mentioned, if the need arises we can look at making the badge platform agnostic.

[chris48s]

sounds good 👍