It usually happens when you're just trying to get a build out. Everything looks fine, you haven't touched the core XML in days, and suddenly the compiler throws a fit. You see it in the build output: aapt: error: resource android:attr/lstar not found. It’s annoying. It feels like the tooling is breaking under its own weight, which, to be fair, happens more often than we'd like in the Android ecosystem.
The first time I saw this, I thought I'd accidentally deleted an attribute in a theme file. I hadn't. This error is almost never about your actual code. It’s a compatibility mismatch. Specifically, it's about the Core-ktx library and how it talks to the Android build tools.
Why aapt: error: resource android:attr/lstar not found happens
Android's build system is a house of cards. The lstar attribute was introduced in Android 12 (API 31) to handle specific color contrast ratios for accessibility. It lives inside the androidx.core:core library. If you have a library in your dependency graph that expects this attribute to exist, but your compile SDK version is set to something older—like API 30 or 29—the Android Asset Packaging Tool (AAPT) loses its mind. It looks for android:attr/lstar, realizes it doesn't know what that is because your project is technically "living" in an older version of Android, and the build fails.
It often creeps in through transitive dependencies. You might not have updated your build.gradle file at all. However, if you're using a dynamic versioning strategy (like implementation "androidx.core:core-ktx:+" which you should never do, by the way) or if another library you use updated its own requirements, you get shoved into this mess.
Honest mistake? Probably. But the fix is actually straightforward once you realize the compiler is just asking for a newer dictionary to read the instructions.
The "I Need a Quick Fix" Method
Most developers just want the red text to go away. The fastest way to resolve the aapt: error: resource android:attr/lstar not found issue is to bump your compileSdkVersion.
Open your build.gradle (the app-level one). Look for android { ... }.
Change your compileSdkVersion to 31 or higher.
While you're at it, you should probably update the targetSdkVersion to 31 as well, though compileSdkVersion is the one that usually kills the AAPT process. By setting this to 31, you're telling the compiler, "Hey, I know about the features introduced in Android 12." Once the compiler knows about API 31, it suddenly recognizes lstar and stops complaining.
🔗 Read more: PetSmart App for Android Explained (Simply): How to Actually Make it Work
Does this force you to change your entire app's logic? No. Compiling against a higher SDK doesn't mean your app won't run on older phones. It just means the build tools are using a newer set of definitions during the packaging phase.
What if you can't update the SDK?
Sometimes you're stuck. Maybe a client has a strict "no API 31" rule for some archaic reason, or you're maintaining a legacy codebase where a bump in SDK version triggers a cascade of 400 other errors. In that specific, slightly painful scenario, you have to force a downgrade of the Core library.
The lstar attribute specifically started appearing in androidx.core:core:1.7.0. If you force your project to use version 1.6.0, the error usually vanishes. You do this by adding a resolution strategy in your project-level build.gradle or by explicitly defining the version in your app-level dependencies.
Basically, you’re telling Gradle: "I don't care what my other libraries want; we are using version 1.6.0 of the core library."
Digging into the Dependency Tree
If you're still seeing the error after a clean and rebuild, you’ve got a rogue dependency. You need to see who is bringing in the modern Core library. Run this command in your terminal:
./gradlew app:dependencies
It’s going to spit out a massive tree. Search for androidx.core:core:1.7.0 (or higher). You’ll likely see it nested under something like androidx.appcompat or a third-party UI library. This is the "Aha!" moment. Once you identify the culprit, you can decide whether to update your whole project or just pin that specific library to an older version.
The Material Design Connection
Surprisingly, many people run into aapt: error: resource android:attr/lstar not found after adding the Material Components library. Material 1.5.0 and higher relies on those newer color attributes. If you're trying to use the latest Material Design features while keeping your project compiled at API 30, it’s not going to happen. The two are fundamentally linked.
I've seen forum posts suggesting you can just "ignore" the error by adding some ProGuard rules. That's bad advice. ProGuard handles code shrinking and obfuscation; it has zero impact on the AAPT resource packaging phase. If AAPT can't find a resource, the APK won't even generate.
Steps to Verify Success
- Invalidate Caches: Go to
File > Invalidate Caches / Restart. Android Studio likes to hold onto ghosts of previous builds. - Clean Project: Run
./gradlew clean. - Check the Manifest: Ensure there are no hardcoded references to
@android:attr/lstarin your own XML files. It's rare, but sometimes a copy-paste from a StackOverflow answer can introduce it manually. - Sync Gradle: Click that little elephant icon with the blue arrow like your life depends on it.
Real-World Nuance
It's worth noting that while API 31 is the standard fix, we are now well into the era of API 33 and 34. If you're still seeing this error in 2026, you're likely working on a very old project. The most sustainable path is always to keep the compileSdkVersion at the latest stable release. It keeps the build tools happy and prevents these weird attribute-not-found errors from surfacing every time Google decides to tweak the color system.
If you are using a multi-module project, make sure every single module is using the same compileSdkVersion. I've spent hours debugging a build error only to find that module-ui was at 31 while module-data was still at 30. AAPT struggles when it gets conflicting messages from different modules in the same build graph.
Summary of Actionable Steps
- Primary Fix: Set
compileSdkVersion 31(or higher) in your app-levelbuild.gradlefile. This is the most "correct" way to handle it. - Secondary Fix: If you cannot upgrade the SDK, force the core library to an older version by adding
implementation 'androidx.core:core:1.6.0'to your dependencies and ensuring nothing else overrides it. - Audit Dependencies: Use
./gradlew :app:dependenciesto find out which library is dragging in the newerandroidx.coreversion. - Clean Slate: Always perform a
CleanandRebuildafter changing SDK versions to ensure no cached artifacts remain.
Moving forward, keep an eye on your androidx library versions. The jump from 1.6.0 to 1.7.0 in the core library was a breaking change for many because of this exact attribute. Staying current with the compileSdkVersion is usually less painful than trying to pin dozens of libraries to legacy versions.