Theme.AppCompat.NoActionBar: Complete Guide to Hide ActionBar

You just want a clean, full-screen app, but Android keeps throwing a Theme.AppCompat.NoActionBar not found error at you. Frustrating, right? I've been there—staring at a red build log at 2 AM, wondering why something as simple as hiding the ActionBar turns into a dependency nightmare. The truth is, theme.appcompat.noactionbar is the standard solution for removing that default top bar, but it comes with its own set of quirks. In this guide, I'll walk you through everything: from basic setup to fixing the dreaded "resource not found" error, and even migrating to Material Design 3. Let's get your app looking the way you want it.

What Is Theme.AppCompat.NoActionBar and Why Use It?

Understanding the NoActionBar Theme Family

Think of Android themes as outfits for your app. The default Theme.AppCompat is like a business suit—it comes with an ActionBar built in, ready to display your app title and menu items. Theme.AppCompat.NoActionBar is the casual version: it removes that default bar entirely, giving you a blank canvas.

Here's a quick comparison of the common variants:

When Should You Use NoActionBar?

I've used NoActionBar in three main scenarios over the years:

Splash screens and full-screen experiences. Remember the first time you opened a game like Monument Valley? That clean, immersive entry without any system chrome? That's NoActionBar at work. For splash screens, you typically want zero distractions—just your logo and maybe a loading indicator.

Apps using a custom Toolbar. Here's the thing: removing the ActionBar doesn't mean you don't want a top bar at all. It means you want your bar. A media player like Spotify uses a custom Toolbar with album art integration and sliding animations. You can't do that with the default ActionBar.

Material Design 3 apps. If you're building with Material You (Android 12+), the default ActionBar feels outdated. The new top app bar has dynamic colors, rounded corners, and custom behavior that the old ActionBar can't match. NoActionBar gives you the freedom to implement it properly.

How to Apply Theme.AppCompat.NoActionBar in Your Project

Method 1: Setting the Theme in AndroidManifest.xml

This is the most straightforward approach, and honestly, the one I use 90% of the time. Open your AndroidManifest.xml and add the theme attribute to either the <application> tag (for the whole app) or a specific <activity> tag.

For a global application theme:

<application
    android:theme="@style/Theme.AppCompat.NoActionBar"
    ... >

For a single activity (say, your splash screen):

<activity
    android:name=".SplashActivity"
    android:theme="@style/Theme.AppCompat.NoActionBar"
    ... >

The difference matters. Applying it globally means every screen in your app loses the ActionBar. That's fine if you're using a custom Toolbar everywhere. But if you have a settings screen that works fine with the default bar, apply it per-activity instead.

Method 2: Applying the Theme Programmatically with setTheme()

Sometimes you need to decide the theme at runtime—maybe based on user preferences or device capabilities. That's where setTheme() comes in. But here's the critical rule: you must call it before setContentView(). I learned this the hard way after spending an hour debugging a blank screen.

Here's the Kotlin version:

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        setTheme(R.style.Theme_AppCompat_NoActionBar)
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
    }
}

And in Java:

public class MainActivity extends AppCompatActivity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        setTheme(R.style.Theme_AppCompat_NoActionBar);
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
    }
}

Why the strict ordering? Because Android needs to know the theme before it inflates any views. If you call setTheme() after setContentView(), the theme changes won't apply to the already-inflated layout. It's like trying to change the wallpaper after the paint has dried.

Method 3: Creating a Custom NoActionBar Theme in styles.xml

This is where things get interesting. You're not stuck with the default colors and behavior. Create a custom theme that inherits from Theme.AppCompat.NoActionBar and override what you need.

Here's a complete example for styles.xml:

<style name="AppTheme.NoActionBar" parent="Theme.AppCompat.NoActionBar">
    <item name="colorPrimary">@color/primary</item>
    <item name="colorPrimaryDark">@color/primary_dark</item>
    <item name="colorAccent">@color/accent</item>
    <item name="android:statusBarColor">@color/status_bar</item>
</style>

Then apply it in your manifest:

android:theme="@style/AppTheme.NoActionBar"

I usually create a base theme like this for every project. It gives me a single place to tweak colors and behavior without touching the manifest again.

Fixing the 'Theme.AppCompat.NoActionBar Not Found' Error

Root Cause: Missing AppCompat Dependency

This is the most common culprit, and it's embarrassingly simple to fix. The error resource style/Theme.AppCompat.NoActionBar not found means your project doesn't have the AppCompat library. Open your app/build.gradle file and check the dependencies block:

dependencies {
    implementation 'androidx.appcompat:appcompat:1.6.1'
    // other dependencies...
}

If you're using the old support library (anything with com.android.support), you're living in 2017. Migrate to AndroidX. The support library is deprecated and won't receive updates. I've seen projects stuck on appcompat-v7 that work fine until you try to target API 33+, then everything breaks.

Root Cause: Incorrect Theme Inheritance in styles.xml

Here's a mistake I see all the time in code reviews:

Broken theme:

<style name="AppTheme" parent="android:Theme.Material.Light">
    <!-- This won't work with AppCompat activities -->
</style>

Correct theme:

<style name="AppTheme" parent="Theme.AppCompat.Light.NoActionBar">
    <!-- This inherits from AppCompat -->
</style>

The key insight: if your activity extends AppCompatActivity, your theme must inherit from a Theme.AppCompat parent. Using android:Theme.Material directly will give you that "not found" error because the resource IDs don't match. It's like trying to use a Toyota key in a Honda—they're both cars, but the parts aren't interchangeable.

Root Cause: Unity and Cross-Platform Build Issues

This one's a special case that came up in a Unity forum post I came across. A developer was building a Cardboard VR game and hit the exact same error. The twist? The error wasn't in their main project—it was in a plugin's AndroidManifest.xml.

Here's what happens: Unity plugins (like the Cardboard SDK) often ship with their own AndroidManifest.xml that references Theme.AppCompat.NoActionBar. But if the plugin doesn't include the AppCompat library, or if the main project doesn't have it, the build fails.

The fix: Add the AppCompat dependency to your Unity project's build.gradle (usually at Assets/Plugins/Android/mainTemplate.gradle):

dependencies {
    implementation 'androidx.appcompat:appcompat:1.6.1'
}

If that doesn't work, you can override the plugin's manifest by adding your own AndroidManifest.xml in Assets/Plugins/Android/ with a different theme. I've used this approach for Facebook SDK integrations and various ad network plugins.

Theme.AppCompat.NoActionBar vs. Theme.MaterialComponents.NoActionBar: Which to Choose?

Key Differences Between AppCompat and Material Components

Here's the short version: AppCompat is the old guard, MaterialComponents is the new sheriff in town. But "old" doesn't mean "bad"—AppCompat is stable, well-documented, and works on devices back to API 7. MaterialComponents, on the other hand, gives you access to Material Design 3 features like dynamic colors and shape theming.

Migrating from AppCompat to MaterialComponents

If you're ready to make the switch, here's the migration checklist I follow:

Step 1: Update your build.gradle:

dependencies {
    implementation 'com.google.android.material:material:1.11.0'
    implementation 'androidx.appcompat:appcompat:1.6.1'
}

Step 2: Change your theme parent in styles.xml:

<!-- Before -->
<style name="AppTheme" parent="Theme.AppCompat.Light.NoActionBar">

<!-- After -->
<style name="AppTheme" parent="Theme.MaterialComponents.Light.NoActionBar">

Step 3: Update XML attributes. MaterialComponents uses different attribute names:

<!-- AppCompat -->
<item name="colorPrimary">@color/primary</item>
<item name="colorPrimaryDark">@color/primary_dark</item>

<!-- MaterialComponents -->
<item name="colorPrimary">@color/primary</item>
<item name="colorOnPrimary">@color/on_primary</item>

The colorPrimaryDark attribute is deprecated in MaterialComponents. Instead, the system derives it from colorPrimary automatically. This is one of those "trust the system" moments that actually works well.

Using a Toolbar with Theme.AppCompat.NoActionBar

Why Add a Toolbar After Removing the ActionBar?

This seems counterintuitive, right? You remove the ActionBar only to add a Toolbar. But here's the difference: the Toolbar is a View, not a system-level component. You can put it anywhere, animate it, add custom child views, and style it independently.

Think of it this way: the ActionBar is like the built-in shelf in your kitchen—fixed, limited, and hard to modify. The Toolbar is like a modular shelving unit—you can move it, expand it, and customize it to fit your needs.

Step-by-Step: Adding a Toolbar to a NoActionBar Activity

First, add the Toolbar to your layout XML:

<androidx.appcompat.widget.Toolbar
    android:id="@+id/toolbar"
    android:layout_width="match_parent"
    android:layout_height="?attr/actionBarSize"
    android:background="?attr/colorPrimary"
    android:elevation="4dp"
    app:title="My App"
    app:titleTextColor="@android:color/white" />

Then, in your Activity, set it as the ActionBar:

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
        
        val toolbar = findViewById<Toolbar>(R.id.toolbar)
        setSupportActionBar(toolbar)
    }
}

That's it. Now you have a fully functional ActionBar that you can customize. Add a logo, change the navigation icon, or inflate a custom menu—all without touching the system theme.

Best Practices for Theme.AppCompat.NoActionBar in 2026

Handling Different API Levels

Here's a reality check: NoActionBar works from API 7+ with AppCompat, but some attributes behave differently on older devices. For example, android:statusBarColor only works on API 21+. If you're targeting API 19 (Android 4.4), you need to provide fallback themes.

Create a values-v21/styles.xml for modern devices:

<style name="AppTheme.NoActionBar" parent="Theme.AppCompat.NoActionBar">
    <item name="android:statusBarColor">@color/status_bar</item>
    <item name="android:navigationBarColor">@color/nav_bar</item>
</style>

And a values/styles.xml for older devices:

<style name="AppTheme.NoActionBar" parent="Theme.AppCompat.NoActionBar">
    <!-- No statusBarColor here—it won't work on API < 21 -->
</style>

I test on at least two devices: one running Android 4.4 (API 19) and one running Android 14 (API 34). The gap between them is massive, and you'd be surprised what breaks.

Integrating with Jetpack Compose

If you're using Jetpack Compose, you don't need NoActionBar at all. Compose has its own theming system that bypasses the traditional ActionBar entirely. But here's the catch: if you have a mixed app (some screens in Compose, some in Views), you still need NoActionBar for the Activity hosting the Compose content.

Here's how to set up a Compose activity with a NoActionBar theme:

class MainActivity : ComponentActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContent {
            MaterialTheme {
                // Your Compose UI here
            }
        }
    }
}

Notice I didn't call setTheme() or use AppCompatActivity. ComponentActivity doesn't require an ActionBar, so you can skip the NoActionBar theme entirely. But if you're using AppCompatActivity for backward compatibility, apply the theme in the manifest as usual.

Frequently Asked Questions

Why is my Theme.AppCompat.NoActionBar not hiding the ActionBar?

I've debugged this exact issue more times than I can count. Here's your checklist:

1. Is the theme applied to the correct Activity? Check your AndroidManifest.xml. If you applied it to <application> but have a custom theme on a specific <activity>, that activity's theme takes precedence.
2. Does your custom theme inherit from NoActionBar? If you created a custom style but forgot to set the parent, it inherits from nothing—and you get the default ActionBar.
3. Do you have a Toolbar set as ActionBar? If you call setSupportActionBar(), the Toolbar becomes the ActionBar. The theme hides the default bar, but the Toolbar replaces it. This is expected behavior.

What is the difference between Theme.AppCompat.NoActionBar and Theme.AppCompat.Light.NoActionBar?

The short answer: background color. NoActionBar uses a dark background for the status bar and system UI elements. Light.NoActionBar uses a light background. Both hide the ActionBar. I use the light variant for apps with white backgrounds (like reading apps) and the dark variant for media apps or games.

Can I use Theme.AppCompat.NoActionBar with Material Design 3?

Technically, yes. But you're missing out. Material Design 3 (Material You) features like dynamic colors and shape theming require Theme.Material3.DayNight.NoActionBar. If you're starting a new project in 2026, use Material3. If you're maintaining an older app, the migration is straightforward—I covered it earlier in this guide.

How do I remove the ActionBar from only one Activity?

Apply the NoActionBar theme to the specific <activity> tag in your AndroidManifest.xml:

<activity
    android:name=".SplashActivity"
    android:theme="@style/Theme.AppCompat.NoActionBar" />

Leave the <application> tag with your default theme. This way, only SplashActivity loses the ActionBar.

Conclusion

We've covered a lot of ground. From understanding what theme.appcompat.noactionbar actually does, to applying it in three different ways, to fixing the most common errors. The key takeaways:

• Use NoActionBar when you need a clean slate for custom UI, splash screens, or full-screen experiences.
• Always check your AppCompat dependency first when you hit the "not found" error.
• Consider migrating to MaterialComponents.NoActionBar for future-proof apps with Material You support.
• Add a Toolbar after removing the ActionBar—it gives you the flexibility you actually need.

If you're planning a migration from AppCompat to Material Design 3, I've put together a free checklist that covers every step. It's saved me hours on multiple projects, and I think you'll find it useful too.

Download our free Android theme migration checklist to ensure a smooth transition from AppCompat to Material Design 3.