Open andwhysoft opened 2 years ago
This sounds similar to https://github.com/google/dagger/issues/3386. If you're optimizing your sdk r8 is likely removing Hilt's entry points.
Unfortunately r8/proguard isn't related to the issue with the sdk. I will check the app's optimization to see if the issues is from that side maybe.
I have a library module which is utilizing the @OptionalInject on the @AndroidEntryPoint classes with hilt and dagger modules setup to be compatible with both.
The consuming app was originally utilizing dagger which consumed the library properly through dagger. Now the consuming app has migrated over to hilt, however we still would like the library to be utilized through dagger, the reason being to keep the encapsulation of the library separate. We are seeing the below class cast exception when hilt is being utilized in the app.
We are suspecting @OptionalInject potentially doesn't work where the application utilizes hilt, but we are trying to consuming the library as dagger to keep the encapsulation of the library separate. It seems that there will be a check against the parent ojbect that check if it uses hilt and will then default to hilt, which will run into this class cast exception. Is there a way to resolve this issue so that the library is used as dagger even though the library also supports hilt? or would we have to remove hilt from the library to maintain the encapsulation through dagger usage?
I have tried the enableExperimentalClasspathAggregation and enableAggregatingTask in some issue I have found https://github.com/google/dagger/issues/3004, but those don't seem to be exactly pertaining to this issue.