What is ADB? Describe two common commands and what they accomplish.
This tests command-line debugging fluency. Define ADB as a client-server bridge, then give two commands such as adb install for APK deployment and adb logcat for streaming device logs. Red flag: calling it the Android Studio debugger or omitting the daemon.
What's really being asked
The interviewer wants to know if you have real-world debugging experience outside of the IDE GUI. Senior engineers are expected to understand the full communication stack between host and device, automate deployments, and diagnose production issues from logs. This question separates candidates who only click Run from those who can script builds, capture bug reports, and troubleshoot hardware or OS-level problems.
The full answer
First, define ADB accurately as a command-line tool that is part of the Android SDK Platform Tools. Explain that it is a client-server program made of three components: the client on your development machine, a daemon that runs commands on the device or emulator, and a server on your host that manages communication between the client and daemon. Second, provide two concrete commands with exact syntax and clear outcomes. For example, adb install path_to_apk.apk pushes an Android package to a connected device and installs it, which is essential for QA builds or CI pipelines. Another example is adb logcat, which streams system and application log messages in real time, letting you filter by tag or priority to isolate crashes or memory warnings. Third, mention that ADB works over USB or TCP/IP, so you can debug wirelessly after adb tcpip 5555 and adb connect.
The mistakes people make
Calling ADB the Android Studio debugger or an IDE plugin. Confusing it with JDWP, which is the protocol used for Java breakpoint debugging. Giving vague descriptions like you use it to fix bugs without naming commands. Listing adb devices as one of your two primary commands without pairing it with a substantive action like install or logcat. Forgetting that the daemon must be running on the device, which is why adb start-server or adb kill-server are sometimes needed.
What usually comes next
How would you debug an app on a device over Wi-Fi without a USB cable? What is the difference between adb install and adb install -r? How do you filter logcat output to show only error-level messages from a specific package? What happens when adb devices shows unauthorized, and how do you resolve it? How would you capture a bug report using adb bugreport for a non-technical stakeholder?
A concrete example
Imagine a CI pipeline that builds an APK every night. Instead of manually dragging the file to an emulator, the script runs adb install -r app-release.apk to reinstall the existing build, then immediately runs adb logcat -d -s MyApp:D to dump and filter debug logs for the MyApp tag. If the install fails with INSTALL_FAILED_UPDATE_INCOMPATIBLE, the engineer knows to check signing certificates because ADB surfaced the exact package manager error.
Interview question
When automating nightly APK deployments on a headless CI server, which characteristic of ADB makes it suitable for this task?
- a.It streams device logs using adb logcat only when an IDE is open to receive them
- b.It is a client-server program whose command-line client can run without Android Studio or any IDECorrect
- c.It functions as an Android Studio plugin that exposes terminal commands for build automation
- d.It relies on the JDWP protocol to install APKs and manage package deployment
Why? this is the answer
ADB is defined as a standalone client-server command-line tool in the Android SDK Platform Tools, so it can script builds and deployments without an IDE present. The distractor calling it an Android Studio plugin reflects a common misconception, while JDWP is actually the separate protocol used for Java breakpoint debugging, not ADB operations.
Just read this? Test yourself on what you have been reading.
Read the original → developer.android.com
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on android — each one lists the topics its interview covers.
See open roles