Compatibility issues in latest version (from v2.0.3 to v2.0.6) about pandora

[whataa]

The problems do exist.

OKHttpUrlConnection was introduced to implement log interception for Android's UrlConnection, but the library has been abandoned for a long time. The related APIs have been severely disconnected with the update of OKHttp, it is really incompatible, and the issue caused is greater than Proceeds, so I decided to remove it from Pandora.

This change became effective in version 2.1.0

After that, pandora no longer depends on the specific version number of OKHttp, and is fully compatible.

[whataa]

#69

[rafaco]

It sound like the right approach. Cheers!

I think you also introduced Java 8 requirement around the same time. Just in case you add it for OKHttpUrlConnection and you find it easy to remove to support more legacy apps.

[rafaco]

First of all, congratulation for your new plugin, it works like a charm and I love it. I didn't know about this kind of build time injection/reflection and I will definitively investigate your implementation to learn from it. Thanks!

I have tested v2.1.0 and I can confirm that Android R problem is fixed.

Api<21 problem still the same as it's a requirement of OkHttp 4 which still in use. It's a runtime exception on okHttp initialisation and it happen even if you don't have Pandora plugin installed or even if the host app don't use okHttp/retrofit.

Easier fix will be changing minSdkVersion to 21 but it will reduce Pandora compatibility. I would rather downgrade to OkHttp 3, but if you don't want it you could try a runtime fix selectively for lower platform levels. I mean something like preventing okHttp initialisation when running on API<21. It will allow the app to be started with others Pandora goodies but it will probably also stop any communications with backend servers if the host app rely on Retrofit/OkHttp or even a new crash when calling Retrofit Builder from the host app.

[whataa]

Thanks! As the OkHttp's README says:

• OkHttp 4.x works on Android 5.0+ (API level 21+) and Java 8+.
• OkHttp 3.12.x works on Android 2.3+ (API level 9+) and Java 7+.

For minSdkVersion < 21, the project should choose using OkHttp 3.12.x. But since Pandora introduced version 4, you need to exclude it and implementation OkHttp 3.12.x manually:

implementation ("com.github.whataa:pandora:v2.1.0") {
    exclude group: 'com.squareup.okhttp3'
    // or using: transitive false
}
implementation("com.squareup.okhttp3:okhttp:3.12.x")

the APIs Pandora used are included in every OkHttp version. That is, Pandora is independent of the specific version of OkHttp.

[rafaco]

Thank you, this solve completely this issue for me.

In order to help others wanting to support API<21 in modern projects, the higher valid versions are:

• OKHTTP_VERSION = "3.12.10"
• RETROFIT_VERSION = "2.6.4"

But if your projects havesourceCompatibility JavaVersion.VERSION_1_7, previous versions produce tons of warning on build time while performing transformClassesWithPandora and pandora interceptor will not work on runtime despite a success build. They are all AGPBI warnings related to desugaring Retrofit Kotlin methods with R8. To solve this you can downgrade a bit more to following versions:
- OKHTTP_VERSION = "3.8.0"
- RETROFIT_VERSION = "2.3.0"

[rafaco]

I think you also introduced Java 8 requirement around the same time. Just in case you add it for OKHttpUrlConnection and you find it easy to remove to support more legacy apps.

Yes, I can confirm it now, Pandora works again in Java 7 projects when excluding OkHttp 4.x and replacing it by 3.12.10, as Java 8+ requirement came from OkHttp 4.x. Nice one!

My previous comment has wrong info and I will edit it. I was having issues because pandora-noop has okhttp dependency also and I forget to exclude/replace OkHttp there...

@whataa: Do you think Pandora.getInterceptor() still useful after the plugin release? Removing this method from your public interface will allow to remove OkHttp dependency as well from your noop artifact improving the impact on release builds.