[Bug Report & Solution] Root Cause of Grayed-Out ADB Debugging on Debian 13 (Trixie): Broken Google Repository
Hello Chrome OS Engineering Team, After extensive troubleshooting regarding the "Enable ADB debugging" toggle remaining grayed out on managed devices, I have isolated the root cause. It is not an Admin Policy issue, nor a user error. The issue is a missing dependency in the Google Package Repository for Debian 13 (Trixie), which prevents the installation of cros-guest-tools. Without cros-guest-tools, the Chrome OS Host cannot verify the container's integrity or establish the necessary bridges, leading the OS to lock developer features (ADB) as a security fallback. Here is the technical breakdown and the required fix. 1. The Environment Host: Chrome OS (Version 131+) Guest: Debian 13 (Trixie) - Current Stable. Repository Config: /etc/apt/sources.list.d/cros.list deb https://storage.googleapis.com/cros-packages/142 trixie main 2. The Error When attempting to install or update the integration tools via sudo apt install cros-guest-tools, the package manager fails with a hard dependency error: The following packages have unmet dependencies: cros-guest-tools : Depends: cros-im which is a virtual package and is not provided by any available package Running sudo apt search cros-im confirms that this package does not exist in the trixie RELEASE of the repository. 3. The Diagnosis The cros-guest-tools meta-package depends on cros-im (Input Method integration). In Bookworm (Debian 12), this dependency is satisfied (likely by cros-im-default or similar). In Trixie (Debian 13), the cros-im package has not been published or linked in the repository index. 4. The Solution (Action Required from Google) The repository maintainers need to push the missing input method packages to the Trixie DIRECTORY immediately. Required Action: Please ensure cros-im-default (or the architecture-specific equivalent) is added to: https://storage.googleapis.com/cros-packages/142/dists/trixie/main/ Once this dependency is resolvable: cros-guest-tools will install correctly. The Host<->Guest handshake will complete. The "Enable ADB Debugging" toggle will unlock in the Chrome OS Settings. Please escalate this to the Cros Packaging team. Best regards, Christophe RouxThe "Enable ADB Debugging" Maze: A Call for Architectural Clarity, Unified Nomenclature, and UI Improvements
Hello Chrome OS Enterprise Community and Google Product Team, I am an administrator and developer using a managed Chromebook for Android development. For over a month, I have been unable to toggle "Enable ADB debugging" in the Linux (Crostini) settings because it remains grayed out, despite my having full admin access. After weeks of back-and-forth with Google Workspace Support, it has become clear that this is not just a bug, but a profound architectural issue regarding how managed Chrome OS handles policy dependencies and how we navigate the Admin Console. Technical Environment & Stability Context It is important to note that my development environment is not a fresh install, but a long-running, stable workspace. I have been using the same Crostini container for over a year, and recently performed a successful dist-upgrade from Debian 12 (Bookworm) to Debian 13 (Trixie), which is the current Stable release. The fact that Crostini handled this major OS upgrade without requiring a reinstall demonstrates the high quality and robustness of the Chrome OS platform. However, this longevity raises a diagnostic question: Is the ADB toggle logic failing specifically on containers that have migrated through major versions? The Current Situation: A Maze of Hidden Dependencies Support has provided numerous potential fixes, suggesting that the "ADB" feature is not controlled by one switch, but is the result of a complex calculation involving multiple policies scattered across different menus. I have re-checked all the following solutions proposed by Support between Nov 7 and Dec 11, 2025. None have solved the issue: Date Policy Name Exact Admin Console Path Action Taken Nov 7 Developer tools Devices > Chrome > Settings > Users & browsers > Content > Developer tools Set to "Always allow use of built-in developer tools." Nov 21 Linux virtual machines Devices > Chrome > Settings > Users & browsers > Virtual Machines > Linux virtual machines Set to "Allow usage for virtual machines needed to support Linux apps for users." Nov 24 Untrusted sources Devices > Chrome > Settings > Users & browsers > Android applications > Android apps from untrusted sources Set to "Allow" (Required for sideloading). Dec 3 Developer Tools (Refined) Devices > Chrome > Settings > Users & browsers > Content > Developer tools Set to "Allow use of built-in developer tools, except force-installed extensions..." Dec 10 ADB Sideloading Devices > Chrome > Settings > Device settings > Virtual Machines > ADB sideloading Set to "Allow affiliated users of this device to use ADB sideloading." Dec 11 Unaffiliated VMs Devices > Chrome > Settings > Device settings > Virtual Machines > Linux virtual machines for unaffiliated users Set to "Allow usage for virtual machines needed to support Linux apps for unaffiliated users." The Architectural Problem Administrators are currently guessing which combination of "User Settings" and "Device Settings" will result in the feature unlocking. There is no visibility into which specific policy is overriding the others. Furthermore, the UI itself makes locating these settings inefficient. Proposal 1: A "Computed Policy View" We need a diagnostic view in the console. When an Admin looks at a locked setting (like ADB Debugging), the console should display: Status: LOCKED Blocked By: Device Policy > ADB Sideloading OR User Affiliation Check Failed. Proposal 2: A Standardized Nomenclature for Admin Options The Google Admin Console contains thousands of options. Support tickets often fail because describing the path to an option is tedious and prone to error. I propose implementing a Unique Identifier System: Menus/Tabs: assigned a 3-letter nickname. Sections/Options: assigned a numerical ID. Example: Instead of describing a long path, we could simply reference ID: DEV-CHR-DEV-VMS-042 DEV: Menu (Devices) CHR: Product (Chrome) DEV: Tab (Device Settings) VMS: Section (Virtual Machines) 042: Option (ADB Sideloading) Entering this ID into the search bar should take the admin directly to the specific toggle. Proposal 3: Collapsible Sections (Fold/Unfold UI) Currently, settings pages (like Users & browsers) are massive vertical lists. To reach a section near the bottom, an admin must scroll past hundreds of irrelevant options in previous sections. Even when using the "search on page" function, the visual clutter is overwhelming. I propose adding a Fold/Unfold feature: A "Collapse All / Expand All" button at the top of the settings page. Clickable section headers that allow us to hide large blocks of settings we are not currently editing. Conclusion We cannot manage what we cannot find or understand. The current "trial and error" approach to enabling standard developer features is hindering adoption in the enterprise sector. We need better mapping, a precise language (nomenclature), and a more efficient UI to navigate this complex environment. Best regards, Christophe RouxStability vs. Features: The Unique Philosophy of Chrome OS
Hello, There is a distinct difference in how Google manages Android versus Chrome OS, and as a developer, I think it is important to recognize why the Chrome OS strategy is superior for productivity. The Android Approach: Android is a commercial product first. It focuses on features, consumer appeal, and running on everything. The priority is "It works now." The Chrome OS Approach: Chrome OS started small and humble. It has grown slowly, not by chasing trends, but by building a foundation of trust and robustness. I see this robustness daily in the Crostini environment. Recently, upgrading my VM from Debian 12 (Bookworm) to Debian 13 (Trixie) was a pleasure—a real upgrade requiring no reinstallation. This level of stability is rare in the OS world. It proves that Chrome OS is engineered with a long-term vision of quality. The Risk The current rumors about new operating systems or "Android on PC" threaten to undermine this stability. If Google tries to make Chrome OS behave too much like Android—rushing features at the cost of stability—we lose the "high quality" segment. My Request Chrome OS is currently the best bridge between desktop computing and Android mobile development. I urge Google to maintain this "slow and steady" strategy. We don't need a flashy OS; we need a trustable one. Keep building the high-quality, robust platform that Chrome OS has become.Enable ADB debugging is grayed out - This setting is managed by your administrator
This issue was documented in 2021 but with no solution. My Chromebook is managed by my company and I am the manager. But Google tries to find the managed option to unlock for this to work in the administration interface for more than 15 days without success. By the way there are thousands of options in the admin interface it could be a clever feature to number them. If you are in front of the same issue please add your comments to this post. I hope that Google support will succeed to solve the issue soon because I developed my first app for Android on my Chromebook with Android Studio and I was able to download it to my phone before these 15 days.
