Google assembled its best minds to design the most confusing versioning systems possible.
Thanks for that helpful table and the update to your SO post! I still recommend pointing to the network-security-config docs for API 24-25 in your answer to make it 100% complete.
Putting this comment here because it's worth calling out without any applicable advice.
In the face of
Different JSSE providers (Android versions, or JDK)
potential cross signed certificates
different peer certificates served by the webserver
pinning seems really unpredictable. So I'd consider any of the advice above for OkHttp to be assuming that you aren't also trying to use certificate pinning. If you are, talk to your own sizable in-house security team and agree with them.
Some experimental results under a range of contrived conditions.
What about android apps using a WebView component? (A WebView usually uses the default system browser the phone is shipped with, and I'm not sure a workaround could be used for that)
Also, I guess mobile apps relying on Apache Cordova and similar systems could have problems with this change.
I'm not an expert on webviews, I don't know definitive answer and I haven't tested. My incomplete understanding is that webviews would be broken still.
Some links I found on the topic which suggest there isn't a clean fix.
Some links for webviews for bookmarking, but advice is strongly not to do this.
How to use OkHttp for loading resources in WebView (DON'T DO IT)
For webviews one could override onReceivedSslError and then perform a manual chain validation upon SSL_UNTRUSTED error.
In this case root and intermediate certs need to be bundled with the APK.
But I'm suspecting a lot of confused developers anyway, is there a more beautiful solution in the works, or people should ship a fix in their App with a new CA cert added to older Android clients?