Gradle升级至3.0.1后android.R.id等符号找不到问题咨询

Hey there, let's break down what's likely going on here—since you're moving from AGP 2.3.3 to 3.0.1 (I assume you mean the Android Gradle Plugin, not the core Gradle runtime, since that's where the Android-specific build changes live), there are a few key AGP 3.0.x changes that could trigger these android.R.* symbol not found errors:

1. Dependency Configuration Overhaul Broke Android.jar Inclusion #

AGP 3.0 completely redesigned dependency configurations, replacing the old compile with implementation/api and introducing compileOnly (replacing provided). If your project or its dependencies have misconfigured these new configurations, it can break access to the system android.jar (which contains the android.R class):

• Double-check all module build.gradle files: Ensure core Android dependencies (like support libraries) use implementation or api, not compileOnly. Using compileOnly for these would exclude them from the compile classpath entirely.
• Verify no custom build logic is accidentally excluding the android.jar from the compile classpath (this is rare, but possible if you had hacks for retrolambda in place).

2. Resource Compilation & R-Class Generation Got Strict #

AGP 3.0 revamped the resource compilation pipeline and R-class generation logic. Two common issues here:

• Conflicting custom resources: If your project defines custom resources with the same name as system resources (e.g., @+id/home or @+color/white), AGP 3.0's stricter resource merging will prioritize your custom resource over the system one, leading to android.R references failing. Check all your layout/color files for names that clash with android.R identifiers.
• Unqualified R-class references: If you import your app's local R class (e.g., import com.your.app.R) and then try to use android.R without fully qualifying it (like just R.id.home instead of android.R.id.home), AGP 3.0's compiler checks are more aggressive about resolving this to your local R class instead of the system one.

3. Java Version Misconfiguration After Removing Retrolambda #

Since AGP 3.0 natively supports Java 8, removing retrolambda was the right call—but if you didn't update your Java version settings to match, it can cause classpath issues:
Add this to all modules' build.gradle files to ensure proper Java 8 support:

android {
    compileOptions {
        sourceCompatibility JavaVersion.VERSION_1_8
        targetCompatibility JavaVersion.VERSION_1_8
    }
}

If you had retrolambda-specific Java version hacks, make sure those are fully removed so AGP can manage the Java classpath correctly.

4. Module Dependency Visibility Changes #

AGP 3.0 changed how module dependencies expose their code to upper-level modules:

• implementation dependencies are only visible to the module they're declared in.
• api dependencies are exposed to all modules that depend on the current module.

If a library module in your project uses android.R references and is linked to your app module via implementation instead of api, your app module won't be able to resolve those android.R symbols during compilation. Double-check all module dependency declarations to use api when the dependency's code needs to be visible to parent modules.

5. Stubborn Build Cache Residues #

Even though you've cleaned caches, AGP 3.0's new build cache system can leave behind stubborn residues. Try a more thorough reset:

1. Run ./gradlew cleanBuildCache to clear Gradle's build cache.
2. Delete the .gradle folder in your project root, plus all build folders in every module.
3. Re-sync your project and run a full rebuild with ./gradlew assembleDebug.

内容的提问来源于stack exchange，提问作者E. Morice