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

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

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...

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.

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.

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.

@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.

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.

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

I was having a similar issue, thank you for pointing me in the right direction