Android apps on a Chromebook run inside ARC, a container rather than a physically separate phone, which changes the whole ADB story. There is no USB cable involved and no OEM driver to install; instead, ADB debugging connects to the Android container over the loopback network interface, and enabling it requires turning on Linux support first.
ADB debugging for the Android container specifically will not appear as an option in Settings until Linux is enabled, which surprises people who only want to debug an Android app and have no interest in Crostini itself.
Install platform-tools inside the Linux (Crostini) terminal:
sudo apt update
sudo apt install android-tools-adbThen connect to the Android container over its internal network address:
adb connect 100.115.92.2:5555This specific IP is ARC's fixed address on ChromeOS's internal container network, not something that needs to be discovered per-device. Once connected, adb devices should list it as authorized without needing an on-screen confirmation dialog the way a physical phone would, since the Linux container and the Android container are both controlled by the same underlying ChromeOS security boundary.
adb install my-app.apkThis is a common workflow for developers testing an in-progress Android app on Chromebook hardware before publishing, without needing to sideload through a file manager or push the build to the Play Store's internal testing track first.
Unlike a phone, the Chromebook's Android environment is a container inside ChromeOS, not a separate bootable partition with its own bootloader. Concepts like Fastboot, bootloader unlocking, or flashing a boot image do not apply to the ARC container at all — those terms only make sense for the Chromebook's own hardware, which uses a completely separate developer mode and firmware-level unlock process, unrelated to anything covered here.
On a Chromebook enrolled in a Google Admin or school device policy, the Developers section under Settings is frequently disabled entirely by administrator policy, and no amount of toggling in the UI will reveal the ADB debugging option. If Linux development is missing from Settings on a managed device, this is a policy restriction, not a bug, and requires an administrator to change the device policy rather than any local workaround.
Because the connection is over ARC's internal loopback network rather than USB, none of the driver installation, cable quality, or Device Manager troubleshooting that applies to phone ADB setups is relevant here at all. If adb connect fails, the first things to check are that ADB debugging is actually toggled on and that the Chromebook was rebooted after enabling it — not a cable or a missing driver.
Because Linux (Crostini) and the Android container (ARC) are separate isolated environments on ChromeOS, an APK built or downloaded inside the Linux terminal is not automatically visible to adb install unless it lives in the shared "Linux files" folder ChromeOS exposes to both sides. Placing the APK there before running the install command avoids a confusing "file not found" error that has nothing to do with ADB itself and everything to do with which filesystem the file actually landed in.
ARC's performance characteristics differ from a real phone running the same Android version, particularly on lower-end Chromebook hardware, since the container shares CPU and memory budget with ChromeOS itself and any other running apps. An app that behaves fine when debugged this way should still be spot-checked on real phone hardware before assuming its performance profile is representative, especially for anything sensitive to frame timing or background execution limits.