Recent searches


No recent searches

R8 obfluscation causing reflection issues



Posted Nov 10, 2021

Hello,
I have a problem with obfluscation. I am using:
- R8 version 3.0.73 (newest by default)
- Gradle-tools 7.01
- Kotlin plugin 1.5.21

For some time, I observed many problems that are caused by obfluscation. Often when I used reflection, getClass() method returns wrong type (sometimes entirely different package). I would like to post some logs or reports, but is more a general problem. Could you help me with any advice how to deal with it?

Regards,
Maciej


0

6

6 comments

image avatar

Mick O'Donnell

Zendesk Product Manager

Hi Maciej!

Thanks for your comment. Firstly, can you let us know which SDK you are using, and we can see if we can help you out please? 

Secondly, just in case you haven't seen it, we have a known issue with R8 impacted our Classic SDKs (Support SDK and Chat SDK) documented here. However, as you're currently using Gradle 7.01, then I suspect that this isn't your issue.

We have recently observed an issue, again impact the Chat SDK v2 caused by upgrading from Gradle 4.2.X to 7.0.1 in which serialization of certain external dependencies, namely okhttp, can cause use of reflection to break. The workaround for this is to include the follow ProGuard rules in your app:

-keep class okhttp3.** { *; }
-keepnames class okhttp3.** { *; }

If you are indeed using the Chat SDK for Android, please give this work-around a go (we'll have a hotfix release shortly).

If you're using a different SDK, let us know, this won't help you. :)

0


Hi Mick,

thanks for quick reply! Unfortunately, on my end, I couldn't fully test your workaround till today...

What's even more unfortunate, it doesn't work - I know, that you had warned me, that it only works for Chat SDK, but I tried anyway :)

We don't use Chat SDK, only Support SDK, here is a bit more information about our setup:

- minSDKVersion 28
- targetSDKVersion 30
- androidx.appcompat:appcompat:1.2.0
- androidx.core:core-ktx:1.6.0

Do you have any more ideas, how can we overcome this problem?

 

0


image avatar

Mick O'Donnell

Zendesk Product Manager

Sorry Maciej,

I'm afraid not, this sounds like a different issue to the one that we are aware of. Can I ask you a little bit about your setup please?
1. Did this issue occur before you using R8 for obfuscation with the Support SDK? 
2. Which packages are this classes (that are being returned incorrectly) in? Are you in the Support SDK itself, or possible one of its external dependencies?

0


No worries Mick - maybe more information will guide us to proper solution :)

1. No, it didn't. We used R8 for some time. I tried to track any recent changes in our configuration, but nothing obvious popped up. I also tested previous versions of R8, but each library above 3.0 produces same issue, while versions below 3.0 throw java.lang.IllegalAccessError. There is probably some correlation between our R8, Gradle and Support SDK versions.

2. Mostly it's our custom code. The case is like this:
2.1 We perform http request with our custom library, that is a wrapper around OKHTTP
2.2 We pass in that request expected response type
2.3 Once we receive response, we use getClass() method on responseType object passed from called request in order to properly parse newly received responseData object.
2.4 During this step, we should parse given object, but we receive entirely different Type from getClass() method, so process breaks here. To visualize error level, we expect package com.company.core.api.framework.implementation, but we get instead com.company.core.api.standard.model.

0


image avatar

Mick O'Donnell

Zendesk Product Manager

Thanks Maciej,

This is a strange one, and not an error that we're currently tracking if indeed there's an issue with the Support SDK. I'm going to start an internal investigation into this in Zendesk. I'm afraid that we won't be able to solve your issue in this Community Post. Could you please start a conversation on Zendesk Support (widget in the bottom right of the screen) with the info that you've provided about, and we can investigate further.

I'll update this post directly with the outcome of our own internal investigation once we have it.

Kind regards,

Mick

0


Ok Mick, I will do so.

Nonetheless, thanks for the help!

Cheers,
Maciej

0


Please sign in to leave a comment.

Didn't find what you're looking for?

New post