Fixed
Status Update
Comments
ad...@google.com <ad...@google.com> #2
As a workaround, have you tried the butterknife-gradle-plugin and using R2.layouts with your annotations?
https://github.com/JakeWharton/butterknife#library-projects
This will generate final IDs that you can use in your @ContentView annotation.
This will generate final IDs that you can use in your @ContentView annotation.
ki...@google.com <ki...@google.com> #3
R2 requires special handling for use by an annotation processor only. It's not a direct replacement for R as its value is effectively opaque.
al...@google.com <al...@google.com> #4
As #3 suggests, the "workaround" from #2 does not actually seem to work. Resources$NotFoundException
ap...@google.com <ap...@google.com> #5
I would advocate for this annotations removal if it's still in alpha.
hu...@google.com <hu...@google.com> #6
From my perspective a more forward-looking solution would be to conceive a way to make resource IDs final again. In a modularized world, having them be non-final leads to nothing but problems. It was a lesser problem back when they were made non-final originally (somewhere in Jelly Bean I believe).
pa...@google.com <pa...@google.com> #7
I'd rather eliminate the need to have anyone use an R.layout or R.id reference. You don't care about final IDs when you never touch them directly. Layout XMLs are a schema and we should treat them as such by generating interaction types that abstract the underlying mechanics.
Description
Exception:
Caused by: java.lang.ClassNotFoundException: Didn't find class "androidx.core.os.ResultReceiver"
ResultReceiver in AndroidX Core, it is still in package android/support/v4/os:
Sample project:
Android Studio:
Android Studio 3.3
Build #AI-182.5107.16.33.5199772, built on December 25, 2018
JRE: 1.8.0_152-release-1248-b01 x86_64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
macOS 10.13.6