Bump requirements to Android 5+, Java 8+

[swankjesse]

For the release OkHttp 3.13 I’d like to change our requirements from this:

• Android 2.3+ (released December 6, 2010)
• Java 7+ (released July 2011)

To this:

• Android 5.0+ (released November 12, 2014)
• Java 8+ (released March 2014)

These minimums ensure our TLS stack supports both TLSv1.2 and ALPN. Requiring TLSv1.2 is important because we’re soon going to disable TLSv1.0 and TLSv1.1 by default!

I think we want to ship Java 8 bytecode and use lambas and method references. Downstream Android applications may need to enable desugaring in D8 when building APKs.

We should avoid hard requirements on Java 8 APIs (java.time). We will instead continue to offer them as convenience overloads. Java 8 APIs aren’t available until API 26 (released August 2017).

[Tolriq]

😢 I'm min API 16 with a relatively large user base on those devices as they repurpose their old devices as advanced remotes. (70K+)

90% of my user base do not need or use https isn't there a way to continue to support those?
Everything is API 16 on Google side, it's a little too early for dropping.

As I also use Okio and Moshi a lot, I fear that at some point not updating OkHttp will force no more updating Okio and Moshi and this will be a real issue (Specially with the incoming coroutines support)

[yschimke]

Would we consider releasing 3.12.x with critical security fixes, or just abandon really old clients? FWIW I'm for this, I just think it's worth stating what the plan would be.

[swankjesse]

@yschimke Exactly. We’ll do long term fixes on the 3.12 branch, but new features will require newer devices.

[Tolriq]

@swankjesse what about Okio?

Currently OkHttp does not officially support Okio 2.0 but it works, since it's not official I suppose it can break at any point.
How will Okio evolution be handled to not be problematic?

[swankjesse]

OkHttp works with Okio 2, but doesn't require it. If you find bugs, we’ll fix ’em.

As for a general policy on what platforms we’ll require, it’s difficult because there’s many competing trade-offs. We want to our libraries to be secure, small, correct, and fast. Usually in that order of preference!

Requiring Android 5 is about TLSv1.2. We might also be able to get it working on Android 4.4 since that release has some opt-in support for TLSv1.2. Needs investigation!

[Tolriq]

My concern are caused because for example Moshi 1.8 did require Okio 2.1 and did not work with 2.0.

From your writing, if couroutines are added in Okio 2.x and not 3.x I can assume that it should work with OkHttp 3.12.x and you'll make necessary fixes if necessary?

Dropping 70K users with a large part paid ones is not an easy thing to do, specially when I maintain an app since more than 7 years and have a close relationship with the users.

Android 4.4 would be nice it's 85% of those 70k and seems more acceptable, even if a solution without https support for 16+ would be nice too.

Or is there a way to have Okio linked for Moshi and other usage but tell OkHttp to not use it at runtime?

[swankjesse]

Moshi 1.8 required a new API, BufferedSource.peek(). We added that API to both Okio’s 1.x branch (1.16) and the 2.x branch (2.1). In that case we went out of our way to keep Okio 1.x working for users that weren’t ready for a Kotlin upgrade.

When OkHttp starts requiring Android 5+, you’ll have a choice:

• Use the new version in your app. Get modern TLS policy and new OkHttp features.
• Stay behind on the old version. We’ll backport critical fixes as patch releases.

And if you’re willing to suffer some complexity, you can have it both ways. Ship OkHttp 3.12.x to old devices, and later releases to newer ones.

[Tolriq]

I was maybe not clear, I do understand the implication about OkHttp and how to handle it.

The issue is about keeping OkHttp 3.12 preventing me to update the other things (Okio/Moshi) due to breaking changes that would be incompatible with OkHttp 3.12. If moshi 1.9 fix an issue for me or improve performance and require Okio 2.2 that does not work with OkHttp 3.12 then I will have an issue.

I already do ABI split, adding SDK split would start to be really hard to manage from version numbering point of view and would not solve this other libraries update issue.

If you can stay API 19+ I can plan and announce a 16-18 drop in the coming months, if you keep 21+ then I need to start a complete analysis about my internal Okio / Moshi usages to ensure to issues in the future with my planned refactoring and usages and eventually seek for alternatives.

[swankjesse]

All future releases of Okio 1.x and 2.x will work with OkHttp 3.12.x. We’re pretty strict about compatibility!

[Tolriq]

Ok thanks that was the main blocking point from my first comment :)

Now I'll just hope you'll find a way for 19+ to simplify my future life.

[vibin]

Can we be sure that TLS v1.2 is enabled on all devices on API 21, including Samsung? See #2372 (comment).