Introduction

When old Android projects show an AppCompat v7 r21 error in values.xml, the root cause is usually not the XML file itself. It is usually a version mismatch between the support library, the Android SDK level, build tools, or Gradle configuration. In other words, values.xml is where the resource merger fails, but the real fix is usually in project setup.

Why This Error Appears

AppCompat v7 r21 came from the old Android support-library era. Those libraries expected your project to compile against an appropriate Android API level and to use compatible build tooling.

Common failure patterns were:

• 'compileSdkVersion too low for the library'
• mismatched support-library versions across modules
• stale generated build artifacts
• mixing old support libraries with newer AndroidX-era dependencies

So even if the build log points at values.xml, the XML file is often only the symptom.

Check the SDK and Dependency Versions First

In older support-library projects, AppCompat r21 was tied to Android 5.0 era tooling. The first thing to inspect is the module Gradle file.

A historically correct old-style setup looked like:

1android {
2    compileSdkVersion 21
3    defaultConfig {
4        minSdkVersion 14
5        targetSdkVersion 21
6    }
7}
8
9dependencies {
10    implementation "com.android.support:appcompat-v7:21.0.3"
11}

If the project uses appcompat-v7:21.x, all related support libraries should usually be kept on matching versions.

Clean Out Mismatched Support Dependencies

Older Android builds were particularly sensitive to mixing versions like:

• 'appcompat-v7:21.0.3'
• 'support-v4:22.x'
• 'recyclerview-v7:23.x'

That kind of mismatch often triggers resource merge failures. Align the old support libraries to the same family version, or better, migrate the project fully to AndroidX if the codebase allows it.

For modern projects, the cleaner equivalent is:

1android {
2    compileSdkVersion 34
3    defaultConfig {
4        minSdkVersion 21
5        targetSdkVersion 34
6    }
7}
8
9dependencies {
10    implementation "androidx.appcompat:appcompat:1.7.0"
11}

Do not mix com.android.support artifacts with AndroidX artifacts in the same migration state unless you know exactly why.

Clean and Rebuild

Resource merge issues can persist after a configuration fix because old generated files remain in the build directory. A clean rebuild is often necessary.

./gradlew clean
./gradlew assembleDebug --stacktrace

If the project is very old, also confirm that Android Studio is using an installed SDK platform that matches the declared compile SDK.

Read the First Real Error, Not the Last XML Line

Build output often ends with a noisy values.xml failure, but the earlier lines usually reveal the real problem:

• missing attribute
• duplicate resource
• unsupported theme parent
• wrong dependency family

This is why reading only the last error line wastes time on the wrong file.

When Migration Is the Better Fix

If the project is still using AppCompat v7 r21 today, the long-term fix is usually migration, not endless patching. The old support libraries are legacy technology. Even if you unblock the build, the project remains harder to maintain than an AndroidX-based equivalent.

That does not mean you must migrate immediately to solve one build break. It means you should treat the build fix as a temporary stabilization step if the repository is still pinned to support-library-era dependencies.

Common Pitfalls

• Editing values.xml directly when the real issue is dependency or SDK mismatch.
• Mixing different old support-library versions in one project.
• Mixing com.android.support dependencies with AndroidX during partial migration.
• Forgetting to clean and rebuild after dependency alignment.
• Reading only the final XML error line instead of the earlier resource-merge messages.

Summary

• AppCompat v7 r21 values.xml errors are usually project-configuration problems, not literal XML mistakes.
• Check compileSdkVersion, dependency alignment, and support-library consistency first.
• Clean and rebuild after making configuration changes.
• Use the first real resource-merge error, not only the last XML failure line.
• If the project is still on old support libraries, plan an AndroidX migration for long-term stability.