Building a Custom Launcher for ChromeOS

Last Updated : 15 May 2026

11 Views

#technology

Adℹ

Building a launcher for Android is already unusual because launchers are deeply tied to the operating system itself. They are not just normal apps. They control navigation, wallpapers, multitasking, widgets and the overall feel of the device.

Building one for ChromeOS is even stranger

I recently started adapting Be nice, my Android launcher project to work better on ChromeOS because I use my Chromebook more like a giant Android tablet than a traditional desktop machine. ChromeOS supports Android apps through ARC (Android Runtime for Chrome), which sounds great in theory, but things become complicated the moment you try building something launcher-like.

The first major issue appears immediately: ChromeOS does not allow Android launchers to become true launchers.

On normal Android devices, switching launchers is simple. You request the home role or open the system home settings and let the user select your app as the default launcher.


fun changeDefaultHomeApp() {
  val intent = Intent(Settings.ACTION_HOME_SETTINGS).apply {
    addFlags(Intent.FLAG_ACTIVITY_NEW_TASK)
  }

  if (
    context.packageManager.resolveActivity(
      intent,
      PackageManager.MATCH_DEFAULT_ONLY
    ) != null
  ) {
    context.startActivity(intent)
  }
}

On ChromeOS, this simply does not work.

Instead of becoming the actual home environment, the launcher behaves like a regular Android app running inside a window. Pressing the Everything Button still opens ChromeOS. Swiping home still exits into the native shell. Your launcher never truly replaces the desktop experience. That completely changes the mental model.

The launcher can still launch apps, render widgets, manage layouts and simulate parts of the Android experience, but it never gains the system-level privileges launchers normally expect. And honestly, this affects much more than navigation.

One of the strangest issues involved wallpapers.

On Android phones and tablets, Be nice behaves like a traditional launcher. The theme enables wallpaper rendering behind transparent UI layers:


<style
  name="Theme.BeNice"
  parent="Theme.AppCompat.DayNight.NoActionBar">

  <item name="android:windowShowWallpaper">
    true
  </item>

  <item name="android:windowBackground">
    @android:color/transparent
  </item>
</style>

The Compose UI also keeps the main surface transparent:


Scaffold(
  containerColor = ComposeColor.Transparent
)

On phones, this works beautifully because the launcher truly sits on top of the system wallpaper layer.

ChromeOS breaks that assumption entirely.

ARC apps run inside desktop-managed windows and ChromeOS intentionally prevents fully transparent Android windows from behaving normally. Google’s documentation explains why: completely transparent windows would break desktop composition, event handling and window boundaries. To avoid this, ChromeOS draws a semi-transparent layer behind Android windows instead of exposing the real desktop wallpaper directly. That explains why launcher transparency on ChromeOS often looks broken, muddy or simply black.

Developers and users have reported exactly the same behavior across multiple launcher apps. Many Android launchers on ChromeOS show black backgrounds because ARC does not expose wallpaper composition the same way standard Android does. Eventually I stopped fighting the platform.

Instead of pretending ARC behaved like a real launcher environment, I switched to opaque backgrounds on ChromeOS while preserving transparent wallpaper rendering on phones and tablets.


Scaffold(
  containerColor =
    if (defaultAppsManager.isRunningOnChromeOs()) {
      MaterialTheme.colorScheme.background
    } else {
      ComposeColor.Transparent
    }
)

Technically, this solution is less exciting. Visually, though, it is far more honest. Another interesting problem involved launcher detection. Normally, Android launchers can check whether they currently hold the home role using RoleManager.


val roleManager =
  context.getSystemService(RoleManager::class.java)

return roleManager?.isRoleHeld(
  RoleManager.ROLE_HOME
) == true

But ChromeOS never grants that role to Android launchers. That meant Be nice permanently believed it was not the launcher, which caused completely wrong behavior in parts of the app.

Originally, when Be nice was not the default launcher, tapping apps launched them in split-screen multitasking mode instead of standard fullscreen mode. That behavior made sense on phones. It made no sense on ChromeOS.

To solve this, I added explicit ChromeOS detection and intentionally forced the app into launcher mode whenever ARC was detected.


private fun detectIsHomeApp(): Boolean {

  if (isRunningOnChromeOs()) {
    return true
  }

  if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.Q) {

    val roleManager =
      context.getSystemService(RoleManager::class.java)

    return roleManager?.isRoleHeld(
      RoleManager.ROLE_HOME
    ) == true

  } else {

    val intent = Intent(Intent.ACTION_MAIN).apply {
      addCategory(Intent.CATEGORY_HOME)
    }

    val resolveInfo =
      context.packageManager.resolveActivity(
        intent,
        PackageManager.MATCH_DEFAULT_ONLY
      )

    return resolveInfo?.activityInfo?.packageName ==
      context.packageName
  }
}

Detecting ChromeOS itself turned out to be surprisingly unreliable. The expected Chromebook feature flag was missing on some ARC and ARCVM builds, so relying on a single system feature check failed on real devices.

The final implementation became a combination of multiple feature probes:


fun isRunningOnChromeOs(): Boolean {

  val pm = context.packageManager

  return pm.hasSystemFeature(
    SYSTEM_FEATURE_TYPE_CHROMEBOOK
  ) ||

  pm.hasSystemFeature(
    SYSTEM_FEATURE_ARC
  ) ||

  pm.hasSystemFeature(
    SYSTEM_FEATURE_ARC_DEVICE_MANAGEMENT
  )
}

This was not about perfectly defining ChromeOS philosophically. It was about detecting when the platform diverged enough from standard Android that launcher behavior needed to change. And honestly, that became the recurring theme of the entire project.

ChromeOS constantly sits in an awkward middle ground where Android APIs technically exist, but the surrounding assumptions no longer hold.

Android expects fullscreen task-based experiences.
ChromeOS expects resizable desktop windows.
Android launchers expect wallpaper ownership.
ChromeOS owns the desktop shell.
Android multitasking assumes task stacks.
ChromeOS wraps ARC apps inside desktop-managed windows.

That mismatch creates strange edge cases everywhere. One particularly frustrating bug involved split-screen automation. Be nice originally specialized in launching two apps side-by-side using Android split-screen APIs. On ChromeOS, attempting adjacent launches frequently caused the originating app window to stop rendering entirely and become a black rectangle.

The app technically remained alive. It just stopped drawing. Issues like this are especially frustrating because they sit somewhere between Android rendering, ARC window management, GPU composition and ChromeOS desktop behavior. And unfortunately, launcher-style apps stress exactly those systems more aggressively than normal Android apps.

The strange thing is that despite all these limitations, the experience is still surprisingly close to working. That is what makes launcher development on ChromeOS both fascinating and frustrating at the same time.

You constantly feel like you are 80% of the way toward a genuinely good desktop Android launcher experience before running into another system-level limitation you cannot control. And eventually, you stop trying to replace the shell entirely.

Instead, the goal becomes building launcher-like workflows that coexist with ChromeOS instead of fighting it.

Building one for ChromeOS is even stranger

I recently started adapting Be nice, my Android launcher project to work better on ChromeOS because I use my Chromebook more like a giant Android tablet\nthan a traditional desktop machine. ChromeOS supports Android apps through ARC (Android Runtime for Chrome), which sounds great in theory,\nbut things become complicated the moment you try building something launcher-like.

The first major issue appears immediately: ChromeOS does not allow Android launchers to become true launchers.

On normal Android devices, switching launchers is simple. You request the home role or open the system home settings and let the user select your app\nas the default launcher.

\nfun changeDefaultHomeApp() {\n  val intent = Intent(Settings.ACTION_HOME_SETTINGS).apply {\n    addFlags(Intent.FLAG_ACTIVITY_NEW_TASK)\n  }\n\n  if (\n    context.packageManager.resolveActivity(\n      intent,\n      PackageManager.MATCH_DEFAULT_ONLY\n    ) != null\n  ) {\n    context.startActivity(intent)\n  }\n}\n

On ChromeOS, this simply does not work.

Instead of becoming the actual home environment, the launcher behaves like a regular Android app running inside a window. Pressing the Everything Button\nstill opens ChromeOS. Swiping home still exits into the native shell. Your launcher never truly replaces the desktop experience.\nThat completely changes the mental model.

The launcher can still launch apps, render widgets, manage layouts and simulate parts of the Android experience, but it never gains the system-level\nprivileges launchers normally expect.\nAnd honestly, this affects much more than navigation.

One of the strangest issues involved wallpapers.

On Android phones and tablets, Be nice behaves like a traditional launcher. The theme enables wallpaper rendering behind transparent UI layers:

\n<style\n  name=\"Theme.BeNice\"\n  parent=\"Theme.AppCompat.DayNight.NoActionBar\">\n\n  <item name=\"android:windowShowWallpaper\">\n    true\n  </item>\n\n  <item name=\"android:windowBackground\">\n    @android:color/transparent\n  </item>\n</style>\n

The Compose UI also keeps the main surface transparent:

\nScaffold(\n  containerColor = ComposeColor.Transparent\n)\n

On phones, this works beautifully because the launcher truly sits on top of the system wallpaper layer.

ChromeOS breaks that assumption entirely.

ARC apps run inside desktop-managed windows and ChromeOS intentionally prevents fully transparent Android windows from behaving normally.\nGoogle’s documentation explains why: completely transparent windows would break desktop composition, event handling and window boundaries.\nTo avoid this, ChromeOS draws a semi-transparent layer behind Android windows instead of exposing the real desktop wallpaper directly.\nThat explains why launcher transparency on ChromeOS often looks broken, muddy or simply black.

Developers and users have reported exactly the same behavior across multiple launcher apps. Many Android launchers on ChromeOS show black backgrounds\nbecause ARC does not expose wallpaper composition the same way standard Android does.\nEventually I stopped fighting the platform.

Instead of pretending ARC behaved like a real launcher environment, I switched to opaque backgrounds on ChromeOS while preserving transparent wallpaper\nrendering on phones and tablets.

\nScaffold(\n  containerColor =\n    if (defaultAppsManager.isRunningOnChromeOs()) {\n      MaterialTheme.colorScheme.background\n    } else {\n      ComposeColor.Transparent\n    }\n)\n

Technically, this solution is less exciting.\nVisually, though, it is far more honest.\nAnother interesting problem involved launcher detection.\nNormally, Android launchers can check whether they currently hold the home role using RoleManager.

\nval roleManager =\n  context.getSystemService(RoleManager::class.java)\n\nreturn roleManager?.isRoleHeld(\n  RoleManager.ROLE_HOME\n) == true\n\n

But ChromeOS never grants that role to Android launchers.\nThat meant Be nice permanently believed it was not the launcher, which caused completely wrong behavior in parts of the app.

Originally, when Be nice was not the default launcher, tapping apps launched them in split-screen multitasking mode instead of standard fullscreen mode.\nThat behavior made sense on phones.\nIt made no sense on ChromeOS.

To solve this, I added explicit ChromeOS detection and intentionally forced the app into launcher mode whenever ARC was detected.

\nprivate fun detectIsHomeApp(): Boolean {\n\n  if (isRunningOnChromeOs()) {\n    return true\n  }\n\n  if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.Q) {\n\n    val roleManager =\n      context.getSystemService(RoleManager::class.java)\n\n    return roleManager?.isRoleHeld(\n      RoleManager.ROLE_HOME\n    ) == true\n\n  } else {\n\n    val intent = Intent(Intent.ACTION_MAIN).apply {\n      addCategory(Intent.CATEGORY_HOME)\n    }\n\n    val resolveInfo =\n      context.packageManager.resolveActivity(\n        intent,\n        PackageManager.MATCH_DEFAULT_ONLY\n      )\n\n    return resolveInfo?.activityInfo?.packageName ==\n      context.packageName\n  }\n}\n

Detecting ChromeOS itself turned out to be surprisingly unreliable.\nThe expected Chromebook feature flag was missing on some ARC and ARCVM builds, so relying on a single system feature check failed on real devices.

The final implementation became a combination of multiple feature probes:

\nfun isRunningOnChromeOs(): Boolean {\n\n  val pm = context.packageManager\n\n  return pm.hasSystemFeature(\n    SYSTEM_FEATURE_TYPE_CHROMEBOOK\n  ) ||\n\n  pm.hasSystemFeature(\n    SYSTEM_FEATURE_ARC\n  ) ||\n\n  pm.hasSystemFeature(\n    SYSTEM_FEATURE_ARC_DEVICE_MANAGEMENT\n  )\n}\n

This was not about perfectly defining ChromeOS philosophically.\nIt was about detecting when the platform diverged enough from standard Android that launcher behavior needed to change.\nAnd honestly, that became the recurring theme of the entire project.

ChromeOS constantly sits in an awkward middle ground where Android APIs technically exist, but the surrounding assumptions no longer hold.

\n
Android expects fullscreen task-based experiences.
\n
\n
ChromeOS expects resizable desktop windows.
\n
\n
Android launchers expect wallpaper ownership.
\n
\n
ChromeOS owns the desktop shell.
\n
\n
Android multitasking assumes task stacks.
\n
\n
ChromeOS wraps ARC apps inside desktop-managed windows.
\n

That mismatch creates strange edge cases everywhere.\nOne particularly frustrating bug involved split-screen automation.\nBe nice originally specialized in launching two apps side-by-side using Android split-screen APIs. On ChromeOS, attempting adjacent launches frequently\ncaused the originating app window to stop rendering entirely and become a black rectangle.

The app technically remained alive.\nIt just stopped drawing.\nIssues like this are especially frustrating because they sit somewhere between Android rendering, ARC window management, GPU composition and\nChromeOS desktop behavior. And unfortunately, launcher-style apps stress exactly those systems more aggressively than normal Android apps.

The strange thing is that despite all these limitations, the experience is still surprisingly close to working.\nThat is what makes launcher development on ChromeOS both fascinating and frustrating at the same time.

You constantly feel like you are 80% of the way toward a genuinely good desktop Android launcher experience before running into another system-level\nlimitation you cannot control.\nAnd eventually, you stop trying to replace the shell entirely.

Instead, the goal becomes building launcher-like workflows that coexist with ChromeOS instead of fighting it.

","categoryId":192,"subCategoryId":192,"contentFormat":5,"blogId":100,"userId":"MjlfNF84LVsyM10ybi10Q19BTmdlX19JdA==","title":"Building a Custom Launcher for ChromeOS","url":"building-a-custom-launcher-for-chromeos","bannerImage":"","seoDescription":"Building an Android launcher for ChromeOS revealed deep ARC limitations, wallpaper issues, launcher restrictions and desktop UI challenges.","generatedOn":"2026-05-15T06:47:32","updatedOn":"2026-05-15T06:47:32"},"popularContents":[{"id":130,"title":"Rippling SDE-2 Interview Experience (4+ Years Experience) | Offer Received | Coding, LLD & System Design","url":"rippling-sde-2-interview-experience-4-years-experience-offer-received-coding-lld-system-design","description":null,"seoDescription":"Detailed Rippling SDE-2 interview experience with complete 5 rounds, coding questions, rules engine design, system design and preparation tips.","contentType":5,"generatedOn":"2026-10-14T23:20:15.1564304Z","viewCount":0},{"id":173,"title":"Uber SDE-2 Interview Experience : LLD, HLD, DSA & Hiring Manager Round","url":"uber-sde-2-interview-experience-lld-hld-dsa-hiring-manager-round","description":null,"seoDescription":"Read a real Uber SDE-2 interview experience covering DSA, low-level design, high-level system design, behavioral rounds, hiring freeze and key takeaways.","contentType":5,"generatedOn":"2026-10-14T23:20:15.1564318Z","viewCount":0},{"id":165,"title":"Top 50+ SQL Interview Questions and Answers for Intermediate to Advanced","url":"top-sql-interview-questions-and-answers-for-intermediate-to-advanced","description":null,"seoDescription":"Top SQL Interview Questions and Answers for Intermediate to Advanced. Top SQL Interview Questions for experience. Frequently asked SQL interview questions with answers","contentType":2,"generatedOn":"2026-10-14T23:20:15.1558371Z","viewCount":0},{"id":122,"title":"Zepto SDE-1 Interview Experience (Backend Developer) : Real DSA, LLD, Chess Game Design","url":"zepto-sde-1-interview-experience-backend-developer-real-dsa-lld-chess-game-design","description":null,"seoDescription":" Zepto SDE-1 Backend Interview Experience covering DSA, Dynamic Programming, LLD, API Design, DB Schema, OOP & Product Company Rounds.","contentType":5,"generatedOn":"2026-10-14T23:20:15.1564289Z","viewCount":0},{"id":34,"title":"System Design Deep Dive: 25 Essential Interview Questions","url":"system-design-deep-dive-25-essential-interview-questions","description":null,"seoDescription":"","contentType":5,"generatedOn":"2026-10-14T23:20:15.1564217Z","viewCount":0},{"id":35,"title":"Cursor vs Copilot : Which AI Coding Assistant Wins in 2025?","url":"cursor-vs-copilot-which-ai-coding-assistant-truly-wins-in-2025","description":null,"seoDescription":"Compare Cursor vs GitHub Copilot on speed, context awareness, multi-file support, pricing and code quality to choose the best AI coding assistant for developers","contentType":5,"generatedOn":"2026-10-14T23:20:15.1564259Z","viewCount":0},{"id":118,"title":"JioHotstar Staff Software Engineer Interview Experience (Bangalore)","url":"jiohotstar-staff-software-engineer-interview-experience-bangalore","description":null,"seoDescription":"JioHotstar Staff Software Engineer interview experience covering Uber system design, API rate limiter LLD, leadership rounds, bar raiser and HR insights.","contentType":5,"generatedOn":"2026-10-14T23:20:15.1564274Z","viewCount":0},{"id":166,"title":"System Design Interview – BIGGEST Mistakes to Avoid","url":"system-design-interview-biggest-mistakes-to-avoid","description":null,"seoDescription":"Learn the biggest mistakes to avoid in a system design interview, from unclear requirements to poor trade-off analysis. Includes real-world cases, advanced insights and examples to help you ace your next system design interview.","contentType":2,"generatedOn":"2026-10-14T23:20:15.1558387Z","viewCount":0},{"id":213,"title":"Amazon SDE II Interview Experience (Bangalore, Selected) ~ Aug 2026","url":"amazon-sde-ii-interview-experience-bangalore-selected-aug-2026","description":null,"seoDescription":"Amazon SDE II interview experience from Bangalore covering 4 rounds, DSA, LLD, system design, Leadership Principles, coding questions and selection.","contentType":5,"generatedOn":"2026-10-14T23:20:15.156433Z","viewCount":0},{"id":163,"title":"Top 50 SQL Interview Questions and Answers (Beginner to Intermediate)","url":"top-sql-interview-questions-and-answers-beginner-to-intermediate","description":null,"seoDescription":"Top 50 SQL Interview Questions and Answers (Beginner to Intermediate). Top SQL Interview Questions for fresher. Frequently asked SQL interview questions with answers","contentType":2,"generatedOn":"2026-10-14T23:20:15.1558332Z","viewCount":0}],"latestContents":[{"id":219,"title":"6 Tools That Made My Life Easier as a Software Engineer","url":"6-tools-that-made-my-life-easier-as-a-software-engineer","description":null,"seoDescription":"The 6 developer tools I use daily as a software engineer: Git, VS Code, Docker, Postman, Chrome DevTools, and AI assistants, with real tips, mistakes, and trade","contentType":5,"generatedOn":"2026-10-14T23:20:15.1606844Z","viewCount":0},{"id":218,"title":"When Should a Business Use Multiple AI Agents Instead of One?","url":"when-should-a-business-use-multiple-ai-agents-instead-of-one","description":null,"seoDescription":"Single agent or multi-agent AI? Learn the 4 signals that justify splitting agents by knowledge, permissions, and risk, plus routing and handoff tips.","contentType":5,"generatedOn":"2026-10-14T23:20:15.1606914Z","viewCount":0},{"id":216,"title":"AI in Clinical Trials Market Estimated to Experience a Hike in Growth by 2035","url":"ai-in-clinical-trials-market-estimated-to-experience-a-hike-in-growth-by-2035","description":null,"seoDescription":"The exclusive information about market dynamics serves as a valuable guide to predict economic scenarios and initiatives taken to enhance future growth. Our mar","contentType":5,"generatedOn":"2026-10-14T23:20:15.1606928Z","viewCount":0},{"id":217,"title":"AI in Clinical Trials Market Estimated to Experience a Hike in Growth by 2035","url":"ai-in-clinical-trials-market-estimated-to-experience-a-hike-in-growth-by-2035","description":null,"seoDescription":"The exclusive information about market dynamics serves as a valuable guide to predict economic scenarios and initiatives taken to enhance future growth. Our mar","contentType":5,"generatedOn":"2026-10-14T23:20:15.1606942Z","viewCount":0},{"id":215,"title":"What Happens When an AI Agent Doesn't Know the Answer?","url":"what-happens-when-an-ai-agent-doesnt-know-the-answer","description":null,"seoDescription":"Most AI agents fail quietly. They guess instead of saying \"I don't know.\" Here's how to design better fallback and human-handoff behavior.","contentType":5,"generatedOn":"2026-10-14T23:20:15.1606955Z","viewCount":0},{"id":214,"title":"Greedy Algorithms Explained: How They Work, When They Fail and How to Use Them","url":"greedy-algorithms-explained-how-they-work-when-they-fail-and-how-to-use-them","description":null,"seoDescription":"Learn greedy algorithms step by step with C# code Dijkstra, Huffman coding, knapsack and MSTs plus when greedy fails and how to prove it's correct","contentType":5,"generatedOn":"2026-10-14T23:20:15.1606971Z","viewCount":0},{"id":213,"title":"Amazon SDE II Interview Experience (Bangalore, Selected) ~ Aug 2026","url":"amazon-sde-ii-interview-experience-bangalore-selected-aug-2026","description":null,"seoDescription":"Amazon SDE II interview experience from Bangalore covering 4 rounds, DSA, LLD, system design, Leadership Principles, coding questions and selection.","contentType":5,"generatedOn":"2026-10-14T23:20:15.1606985Z","viewCount":0},{"id":212,"title":"How to Get 10x Better AI Answers Without Writing Better Prompts : 10 Proven Techniques","url":"how-to-get-10x-better-ai-answers-without-writing-better-prompts-10-proven-techniques","description":null,"seoDescription":"Get better AI answers without complex prompts. Learn 10 practical techniques using context, examples, tools, feedback, and verification.","contentType":5,"generatedOn":"2026-10-14T23:20:15.1606998Z","viewCount":0},{"id":211,"title":"I Interviewed for a Microsoft SDE I Role. Here's Everything That Happened.","url":"i-interviewed-for-a-microsoft-sde-i-role-heres-everything-that-happened","description":null,"seoDescription":"My real Microsoft SDE I interview experience, all 4 rounds, the exact DSA problems with fully tested solutions, the WhatsApp system design round","contentType":5,"generatedOn":"2026-10-14T23:20:15.1607011Z","viewCount":0},{"id":140,"title":"PolicyBazaar Software Development Engineer (SDE) Interview Experience | DSA, Core CS & System Design","url":"policybazaar-software-development-engineer-sde-interview-experience-dsa-core-cs-system-design","description":null,"seoDescription":"Detailed PolicyBazaar SDE interview experience covering 3 rounds: DSA coding, core CS assessment and system design with key learnings and insights.","contentType":5,"generatedOn":"2026-10-14T23:20:15.1607025Z","viewCount":0}],"relatedContents":[]}}},"source":{"isMobile":false}}; window.__CLIENT_RENDER__ = false;

Building a Custom Launcher for ChromeOS

Building one for ChromeOS is even stranger

Trending Developer Reads

Building one for ChromeOS is even stranger