Update minimum android version

[jack-berg]

We currently enforce android version 21 compatibility with animalsniffer.

@breedx-splk points out that Android API level 26 supports ~94% of devices.

We regularly come across limitations from supporting 21. Can we come up with a formula / heuristic for when its acceptable to update to a later android version? We could do something combining time and cumulative usage like:

We must support the minimum android version which is at least 5 years old and has at least 95% adoption.

The time and adoption levels are debateable.

Some examples of limitations:

• Use StampedLock instead of ReentrantReadWriteLock in Fix delta metric storage concurrency bug #5932 but requires API level 24.
• Use DoubleAdder / LongAdder instead of AtomicDouble / AtomicLong for accumulating sum aggregations, but requires API level 24.
• Want to use Base64 for encoding AnyValue byte arrays as strings in Experimental support for Log AnyValue body #5880 but requires API level 26.
• I've wanted to use CompletableFuture in the past but it requires API level 24.
• We've wanted to use the supplier version of Logger#log in the past but requires API level 26.
• I'm sure there's more examples that I can't think of.

We should definitely coordinate with @open-telemetry/android-maintainers on this. How are you thinking about what minimal android version to support? I don't think we need to be more accommodating than opentelemetry-android.

[LikeTheSalad]

The limited support for Java 8 features is very annoying. At first, we decided to go with API 26 for the Elastic agent based on similar statistics shared by @breedx-splk here. However, at some point someone mentioned that they couldn't use our lib since they were on API 24, so we ended up switching to 24 instead.

My personal experience with API levels is that they are only analyzed at the time of creating a new project and then never/rarely touched again, not because devs don't want to, but because product managers or customers don't like the idea of cutting people off from using the app, even by a small fraction, so making the upgrade tends to be a tough sell, also, some apps are mostly targeted to countries where it's not easy to get a new phone that often, so in those cases making an upgrade could severely affect the overall user base of an app.

That being said, I think API 26 has been a long-awaited upgrade for devs, and every day the idea has gotten easier to sell to management since the adoption of Android 8+ has increased. Also, this year Google Play services have removed support for apps with API levels below 21, which I think raises the bar on what could be a "sweet spot" which I'd say is 24 right now, but it seems like 26 is not that far off.

So my personal opinion is:

• Upgrading from API 21 should be ok 👍
• Going with API 24 should be a smooth transition.
• Going with API 26 will be fine in theory, though it's likely some people would complain about it.

I'm also wondering if there could be something we could do on the Android repo to address some of these issues, for example, shadowing usages of Base64 to point to some class added to the Android repo or something the like... Though I'd have to check how feasible it'd be, but anyway I'm just tossing it out in case we're looking at all the options we might have.

I also think it could be very interesting to get some input from @bidetofevil on this.

[breedx-splk]

I have gathered some statistics from real-world production data in the Splunk RUM product. These were counted by session activation, not by app or unique handset or anything else. Of the Android sessions we saw in the last week, here is the breakdown by os versions and corresponding API level:

os.version	api.version	percent
7	24,25	15.027409
8	26,27	13.723318
13	33	13.325575
11	30	10.672298
12	31,32	10.667673
10	29	10.192003
6	23	8.740085
9	28	8.574559
5	21,22	7.109099
14	34	1.921984
4	other	0.027067

Nothing too surprising to me. There are always as few stragglers that will never upgrade. 😁 The 7% on Android 5 (API 21/22) is obviously higher than I'd have liked, but I'm not sure it's large enough to prevent a reasonable update to 24.

[mateuszrzeszutek]

The 7% on Android 5 (API 21/22) is obviously higher than I'd have liked, but I'm not sure it's large enough to prevent a reasonable update to 24.

There's also another 8.74% on SDK version 23, making it total ~15% of our users <24.

[breedx-splk]

There's also another 8.74% on SDK version 23, making it total ~15% of our users <24.

I think it's important to point out again that it's ~15% of sessions, not of user count.

One user with a huge install base could have impacted these numbers, I honestly don't know. Similarly, many users with smaller install bases could have impacted this as well.

[bidetofevil]

While the total numbers of users/sessions for each SDK version is an important metric to look at when determining min version support, it's also important to look at who those small percentage of users are and what kinds of apps serve their needs. Many of those are older folks with hand-me-down phones, or folks in developing countries who are just happy they have an Android device from 2014 to use, and apps that cater to folks like that would need to support older API versions. While we can't exhaustively support all versions, we shouldn't let numbers along dictate this.

I think looking at what other popular Android libraries' min version support is like would be helpful guide.

• FIrebase requires API 19 (I believe the requirement is the same for Crashlytics, the go-to crash tracker for Android (for now), which is part of the Firebase family now.)
• OkHttp requires API 21
• Picasso, the image loading library with the highest min version requirement is at 21
• Google's set of AndroidX libraries JUST bumped their min version: and it's 19 now

FWIW, Embrace (my employer) has bumped the minSdkVersion to 21 in our latest release too as we found that to be reasonable.

Android versions, unlike even iOS, has a much longer shelf life than what we developers probably want as a result of its popularity amongst low-end/old devices. Apps not wanting to drop updates for these versions will tend to be pretty conservative. If OTel wants to be in that space as a mainstream library, we should probably follow suit.

Given this, I think sticking with 21 for now will likely cause the least amount of friction for adoption and would be what I'd recommend.

[jack-berg]

@bidetofevil do you have any ideas for coming up with a heuristic for selecting a particular min version at any point in time. The examples you give our good and I think its reasonable to follow their lead, but I'd rather not have to have a subjective conversation each time this topic comes up. Like, if OkHttp were to bump to min API 24, and the other libraries stay at min API 21, how do we decide?

[bidetofevil]

@LikeTheSalad made a good suggestion at the Client SIG meeting about pegging support at what the latest Google Play Services version requires, which is currently 21. I think something like that - pegging it to some widely adopted platform library or bellwether like OkHttp- is a reasonable way to go.

Further, I think we can consider a couple of other options to move (at least part of) core development off 21 sooner:

• Have different requirements for the core Android extension than some of auto-instrumentation packages. Basically, we can have the core extension say at 21 so folks can have a barebones OTel experience on Android, but untether more advanced features (in different packages/modules) from that.
• Get to a Stable release with 21 and then have subsequent versions be developed in a "2.0" line with a higher requirement. Managing a legacy branch might not be ideal so maybe we'll stop changes to that unless they're security fixes, and just focus development on the main line which will be 24+ or whatever.

Either way, apps who need to support an Android version below what we want could go with a "lesser" version and at least still have some way of getting OpenTelemetry into their app through the official SDK and extension.

[LikeTheSalad]

In the Client SIG it became clear that upgrading from 21 could cause more troubles than I expected at first glance, so we talked about a couple of alternatives to avoid affecting users who need to stay in 21 while still being able to use newer tools without having to wait for an API version bump from Google Play services or other widely used android tools, as mentioned by @bidetofevil. I was planning to discuss them in today's Java SIG to check how feasible they might be and hopefully find a balanced solution.

[jack-berg]

I like @bidetofevil's recommendation to pin to the latest version from Google Play services. I think we should codify this in our versioning document and clarify that upgrading we DO NOT consider upgrading the minimum android version a breaking change requiring bumping the major version of this project.