Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BUG: use gradle:3.6.0-rc01 Didn't find class "androidx.appcompat.R #817

Closed
weiyf opened this issue Jan 17, 2020 · 9 comments
Closed

BUG: use gradle:3.6.0-rc01 Didn't find class "androidx.appcompat.R #817

weiyf opened this issue Jan 17, 2020 · 9 comments
Assignees
Labels
bug
Milestone

Comments

@weiyf
Copy link

@weiyf weiyf commented Jan 17, 2020

Windows 10
Android Studio 3.6. RC1
objectboxVersion: 2.5.0
classpath 'com.android.tools.build:gradle:3.6.0-rc01'
image

@Hatzen

This comment has been minimized.

Copy link

@Hatzen Hatzen commented Jan 18, 2020

doesnt look like a objectbox problem?
more like multidex and missing paths or a gradle bug

@wangzhanxian

This comment has been minimized.

Copy link

@wangzhanxian wangzhanxian commented Jan 20, 2020

I also encountered this problem. How did you solve it?

@greenrobot-team

This comment has been minimized.

Copy link
Collaborator

@greenrobot-team greenrobot-team commented Jan 20, 2020

Thanks for reporting. Though you missed to mention some important info:

This happens when running the app built with Android Gradle Plugin 3.6.0-rc01.

Syncing and building works fine. Though AS asked to install NDK (Side by side) 20.0.5594570 (revision: 20.0.5594570) because the stripDebugDebugSymbols task FAILED for some reason.

A clean project without ObjectBox is fine, so this may be an issue with the dependencies or R8 rules of the ObjectBox library. Investigating...

@greenrobot-team

This comment has been minimized.

Copy link
Collaborator

@greenrobot-team greenrobot-team commented Jan 20, 2020

Turns out that all R classes, including androidx.appcompat.R are stripped when ObjectBox is added. I suspect this has something to do with the new "simplified R class generation". https://developer.android.com/studio/preview/features#simplified-r-class

Not sure how to fix this, yet. Or if this is an actual bug.

@greenrobot-team

This comment has been minimized.

Copy link
Collaborator

@greenrobot-team greenrobot-team commented Jan 20, 2020

I reported this to the Android Studio team as I'm at a loss of what we are (or not?) doing wrong here. https://issuetracker.google.com/147968317

Edit: Please star it if you are affected.

@greenrobot-team greenrobot-team self-assigned this Jan 20, 2020
@imorlowska

This comment has been minimized.

Copy link

@imorlowska imorlowska commented Jan 23, 2020

Hey there, I work on AGP on the resources pipeline.

Looking at the bug and the linked issue, it does sound like a bug in the objectbox caused by the recent changes in AGP.
Can you explain what does objectbox do to the R classes? Does it in any way modify the classpath?

In 3.6 the change that could be affecting the objectbox is the compile classpath R class flow. Previously we used to re-generate an R class for each dependency at every single module. This meant that if you had App -> Lib A -> Lib B -> AAR, in Lib B we'd generate 2 R classes, in Lib A 3 R classes and in app 4 R classes... And as projects have multiple remote AAR dependencies and often dozens of local modules, this wasn't ideal. In 3.6 we started generating an R class per module and per AAR, and re-using them whenever possible (in libraries). That reduced the number of R classes from n^2 to linear. We still have to re-generate all R classes only at app level, since they need to use final resource IDs (in libraries they were non-final and mock values). To re-use these R classes we add them to the compile classpath, and this is why previously R classes would be visible to all consumers transitively, but now they're only visible (at compile time) to consumers that have direct dependency on that module/AAR or the dependencies are "api" (transitive) and not "implementation".

Another change is that we generate the R classes bytecode directly (skipping R.java completely), but it is unlikely to be related to this issue.

I'm not sure what the objectbox does that could have been affected by this change, especially since this issue seems to be happening at app module. If you could explain how the flow of classes is affected by objectbox then we can work together to find the cause of this issue.

@greenrobot-team

This comment has been minimized.

Copy link
Collaborator

@greenrobot-team greenrobot-team commented Jan 27, 2020

@imorlowska Thanks for your response!

I initially thought this was due to our objectbox-android dependency. It's the only one of our libraries that is an AAR and ships an R class. Thanks to your comments I focused on our Gradle plugin.

Not applying the io.objectbox Gradle plugin (and manually adding implementation "io.objectbox:objectbox-android:$objectboxVersion") resolves the issue. It must be our Gradle plugin then. It should not tamper with R classes that I know of. It "only" adds dependencies, adds some tasks, and configures a Transformer. But looking at that now.

@greenrobot-team

This comment has been minimized.

Copy link
Collaborator

@greenrobot-team greenrobot-team commented Jan 27, 2020

Turns out this is an issue with our Transform implementation. Right now it only copies contents of TransformInvocation.inputs.directoryInputs.

But with Android Gradle Plugin 3.6.0 there is now a JAR containing the R classes in TransformInvocation.inputs.jarInputs (path: ObjectBoxCleanExample\app\build\intermediates\compile_and_runtime_not_namespaced_r_class_jar\debug\R.jar).

Example of the fix:

override fun transform(info: TransformInvocation) {
    info.inputs.forEach { transformInput ->
        // Ensure JARs are copied as well:
        transformInput.jarInputs.forEach {
            it.file.copyTo(
                info.outputProvider.getContentLocation(it.name, inputTypes, scopes, Format.JAR),
                overwrite = true
            )
        }
    }
}

The wrong implementation was due to the misinterpretation that using an input type of DefaultContentType.CLASSES would filter to directories only (including many online examples not caring about jarInputs). But its documentation clearly states "This can be in a Jar file or in a folder.".

This will be fixed in an upcoming release!

Edit: fixed example code.

@greenrobot-team greenrobot-team added the bug label Jan 27, 2020
@greenrobot-team greenrobot-team added this to the 2.5.1 milestone Jan 27, 2020
@greenrobot

This comment has been minimized.

Copy link
Member

@greenrobot greenrobot commented Feb 10, 2020

Please check with the just released 2.5.1 and let us know if it works for you. Thanks again!

@greenrobot greenrobot closed this Feb 10, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants
You can’t perform that action at this time.