Run on a Real Phone and Connect Your Devices

An emulator is a wonderful classroom, but your users do not hold emulators. They hold real phones with real cameras, real fingers, real batteries and real, unpredictable networks. Today you connect your own Android phone to Android Studio, run your app on it, learn the command-line tool that makes all of this possible (adb), and read your first messages in Logcat, the live diary your app writes while it runs.

There is also a practical reason to love this lesson. A real phone uses almost none of your computer's RAM, so if your laptop struggles with the emulator from lesson 04, a phone plugged into a USB port is the best development device you can have. Many working Android developers in Lagos, Ibadan and Nairobi build most of their apps exactly this way.

By the end of this lesson you will be able to:

• Turn on Developer options and USB debugging on a phone.
• Connect a phone by USB and run your app on it from Android Studio.
• Pair and connect a phone over Wi-Fi using Wireless debugging.
• Explain what adb is, and use adb devices, adb install, adb shell, adb push, adb pull and adb logcat.
• Read what device, offline and unauthorized mean in adb devices.
• Mirror and control a physical phone from the Running Devices window.
• Write your own messages with Log.d, Log.i, Log.w and Log.e, and find them in Logcat with filters.
• Troubleshoot "my phone is not detected" step by step.

How this fits the bigger picture: This lesson covers the last codelab of Unit 1's Set up Android Studio pathway in Google's official Android Basics with Compose course, together with the emulator-connection ideas that go with it. Your course outline lists it as How to connect your Android Emulator; on the official pathway page at the time of writing the item is titled How to connect your Android device (item titles shift between releases, so match by content). We cover both ideas: how Studio connects to an emulator, and how it connects to a real phone. The pathway link is at the end.

1. A buildable project and Android Studio's Run button

From lesson 03 you have a project that builds, and from lesson 04 you know that pressing Run builds, installs and launches the app on whichever device is selected in the toolbar's target device menu.

2. What a "debug" connection is

Normally a phone treats your computer as a stranger and refuses to accept apps or commands from it. USB debugging is a switch that says: "I trust computers I have approved to install apps on me and to read my app's diary." Because that is a lot of trust, the switch is hidden and off by default.

3. What adb is (and its three parts)

adb (Android Debug Bridge) is the tool Android Studio uses behind the scenes. It has three parts working together:

 YOUR COMPUTER                                         YOUR PHONE
 +---------------------------+                  +--------------------+
 |  adb client  (you type    |                  |   adbd  (daemon)   |
 |  "adb devices")           |                  |   runs on device   |
 |        |                  |                  +---------^----------+
 |        v                  |   USB cable or Wi-Fi       |
 |  adb server  (background) +----------------------------+
 |  listens on TCP port 5037 |
 +---------------------------+

• The client is the command you type (and the IDE uses).
• The server runs in the background on your computer and manages all device connections. The official documentation says it listens on TCP port 5037.
• The daemon (adbd) runs on each phone or emulator and does the work.

If adb ever "gets stuck", restarting the server fixes most problems (adb kill-server, then adb start-server).

4. Where adb lives

adb is part of Android SDK Platform-Tools, which you installed through the SDK Manager in lesson 02. It sits in the SDK's platform-tools folder. You can find the SDK path in Android Studio under the SDK settings (Languages & Frameworks > Android SDK). Add that folder to your PATH, or run adb using its full path.

5. Your phone and a good cable

You need an Android phone and a USB cable that carries data. Some cheap cables only charge. If you have no phone to spare, you can still do the Logcat half of this lesson on the emulator, since Logcat works the same way on both.

Professional developers use both: emulators for breadth (many screen sizes and Android versions) and real phones for truth.

How Studio sees every device the same way

Both an emulator and a phone appear to Android Studio as entries in the target device menu, because both are devices known to the adb server. In adb devices an emulator is named emulator-5554 (the number is a port), and a phone shows a serial number. This is what "connecting your Android Emulator" really means: the emulator announces itself to the same adb server, and Studio picks it up from there.

$ adb devices
List of devices attached
emulator-5554    device
R58N1234ABC      device

Two devices at once is fine. Studio lets you pick which one receives the app, and when you use adb by hand you choose with -e, -d or -s serial (shown later).

Menu names on phones differ by maker and Android version. The official documentation says "on some devices, the screen may be named or located differently," so use the paths below as a guide and use the Settings search box if you cannot find an item.

Step 1: Turn on Developer options

1. Open Settings and find About phone.
2. Find Build number. On a Google Pixel it is under Settings > About phone > Build number. On recent Samsung Galaxy phones it is under Settings > About phone > Software information > Build number. On other brands, search the About screen.
3. Tap Build number seven times. You may be asked for your screen lock. The phone shows a message such as "You are now a developer!"
4. Go back one screen. Developer options now appears in Settings (on recent Android versions it is usually under Settings > System).

Step 2: Turn on USB debugging

Open Developer options, make sure the main switch at the top is on, and turn on USB debugging. According to the official guide, on Android 9 and above the path is Settings > System > Advanced > Developer options > USB debugging; some phones place it elsewhere.

Safety note: Developer options contain powerful switches. Only change the ones this lesson tells you to. When you are not developing, you can turn USB debugging off again. Never leave your phone connected to computers you do not trust.

Step 3: Prepare your computer

On Linux, after logging back in, run id to confirm plugdev appears in your groups.

Step 4: Connect with USB

1. Plug the phone into the computer with a data cable.
2. Unlock the phone. On the phone, choose a USB mode if asked (file transfer is usually the safest choice; the exact wording varies).
3. A prompt appears on the phone: Allow USB debugging? showing your computer's RSA key fingerprint. Tick Always allow from this computer (only on your own computer) and tap Allow.

Debugging commands do not work until you unlock the phone and accept this prompt. This is the security check that stops strangers' computers from using your phone.

Step 5: Check that your computer sees it

Open the Terminal tool window in Android Studio (or any terminal in the platform-tools folder) and run:

adb devices -l

A working result looks like this (serial and model differ):

List of devices attached
R58N1234ABC device usb:1-2 product:a14 model:SM_A145F device:a14 transport_id:1

The words after the serial number are the state. These are the ones you will meet:

Step 6: Run your app on the phone

Back in Android Studio, open the target device menu in the toolbar. Your phone appears with its model name. Select it and click Run. Android Studio builds the app, copies the APK to the phone through adb, installs it and launches it. Your app's icon is also now in the phone's app list.

You should see the same screen as on the emulator, but on real glass. If your app needs a higher Android version than the phone has (its minSdk from lesson 03), the install fails with a message about the version; either lower minSdk carefully or use a newer device.

No cable? Android 11 and higher can debug over Wi-Fi. Per the official guide you need: the computer and the phone on the same network, Android 11 or higher on the phone, and a recent Android Studio and Platform-Tools.

Pairing with Android Studio (the easy way)

1. On the phone, open Developer options and turn on Wireless debugging. On recent versions this appears under Developer options > Wireless debugging (the path varies by maker). You may be asked to allow it on this network.
2. In Android Studio, choose Pair Devices Using Wi-Fi from the target device menu (or the pairing option in the Device Manager).
3. Choose to pair with a QR code or with a six-digit pairing code. For the QR option, on the phone tap Wireless debugging > Pair device with QR code and scan the code shown in Studio. For the code option, tap Pair device with pairing code on the phone and type the numbers into Studio.
4. Once paired, the phone appears in the target device menu and you can run apps wirelessly.

You pair only once per computer. Afterwards the device reconnects when both are on the same network.

Pairing with the command line

On the phone, open Wireless debugging, then Pair device with pairing code. Note the IP address, port and code shown. On the computer:

adb pair 192.168.1.23:37215

(Use the address and port from your phone.) When asked, type the six-digit code. Success prints a message about successful pairing. Then check the connection:

adb devices

The device may show a name such as adb-R58N1234ABC-xxxxxx._adb-tls-connect._tcp or an IP and port; the state should be device. If it is not listed, the phone's main Wireless debugging screen shows a different IP and port for connecting (not the pairing port). Run:

adb connect 192.168.1.23:41567

with the connect address from that screen.

The older way (Android 10 and lower)

Start over USB first:

adb tcpip 5555
adb connect 192.168.1.23:5555
adb devices

Find the phone's IP address in its Wi-Fi settings. After adb tcpip you may unplug the cable. If the connection drops, run adb connect again, or adb kill-server and start over.

Wireless cautions

• Same network: many public and school Wi-Fi networks isolate devices from each other, which blocks pairing. A phone hotspot or a home router normally works.
• Security: only use wireless debugging on networks you trust, and turn it off afterwards. To forget a computer, use Forget under paired devices in the phone's Wireless debugging screen, or use Revoke USB debugging authorizations in Developer options.
• Data use: installing a debug APK over Wi-Fi uses your local network, not mobile data, but the phone may also be on mobile data. Prefer a local network.
• Official troubleshooting notes for newer versions mention checking adb server-status and mDNS settings when pairing does not discover the phone. If auto-discovery fails, the manual adb pair and adb connect commands above are the reliable fallback.

Android Studio can show your phone's screen inside the Running Devices window, and you can click it with your mouse as if it were an emulator. According to the official guide, this lets you interact with the app, rotate the screen, fold or unfold a foldable phone and adjust volume from Studio. You can start or stop mirroring from Running Devices or from Device Manager, and configure it in the Device Mirroring settings (under Settings > Tools). There is also an option to send the phone's audio to your computer.

Why use it?

• Present your app on a projector or in a screen share without pointing a camera at your phone.
• Type with your computer keyboard.
• Take screenshots and screen recordings straight into your computer.

Cautions from the official documentation:

• Some phones need an extra setting turned on (for example a second USB debugging (Security settings) switch on certain Xiaomi-family devices), then a restart.
• Some phones cannot encode video fast enough, which produces warnings such as too many video encoder errors in the logs.
• Privacy: mirroring over adb tcpip and the channel between Studio and the adb server are not encrypted, so on an untrusted network the content could be intercepted. Do not mirror sensitive screens (banking, passwords) on public Wi-Fi.

Android Studio has a helper for this. Choose Tools > Troubleshoot Device Connections (the name can move between versions). The Connection Assistant walks you through the steps and has a Restart ADB server button. If you prefer to do it yourself, follow this checklist in order:

1. Cable. Try a different cable, ideally the one that came with the phone. Charge-only cables are the number one cause.
2. Port. Use a different USB port; avoid unpowered hubs.
3. Phone unlocked and showing the Allow USB debugging? prompt.
4. USB debugging is really on, and the main Developer options switch is on.
5. USB mode. Some phones need a file-transfer mode, not "charge only".
6. Driver (Windows). Install the maker's USB driver. Check Device Manager in Windows for an unknown device.
7. Linux permissions. Check plugdev and the udev rules, as shown above.
8. Restart adb:

adb kill-server
adb start-server
adb devices

9. Update Platform-Tools in the SDK Manager. The official guide suggests checking whether Studio can run an emulator; if it cannot, updating the SDK Platform-Tools is the first step.
10. Try a second device to find out whether the problem is the cable or the phone.
11. Revoke authorisations in Developer options and plug in again to get a fresh RSA prompt.

You do not need many adb commands, but these few are worth knowing.

adb devices -l # list devices with details
adb -d shell # open a shell on the only USB-connected phone
adb -e shell # open a shell on the only emulator
adb -s R58N1234ABC shell # open a shell on a specific serial
adb install app/build/outputs/apk/debug/app-debug.apk # install an APK
adb shell pm list packages | grep techbase # find your app's package (macOS/Linux)
adb shell pm uninstall com.techbase.hellotechbase # uninstall your app
adb push notes.txt /sdcard/notes.txt # copy a file to the phone
adb pull /sdcard/notes.txt # copy a file from the phone

Notes:

• When more than one device is connected, a plain command fails with adb: more than one device/emulator. Add -d (the only real device), -e (the only emulator) or -s serial.
• Inside adb shell you are inside the phone's small Linux-like command line. Type exit or press Ctrl+D to leave.
• On Windows grep is not available in the default command prompt; use findstr techbase instead, or use PowerShell's Select-String.
• You normally do not need adb install; Android Studio does it when you press Run. It is useful for sharing an APK with a tester, or for installing without Studio.

Sharing your app with a friend: the file at app/build/outputs/apk/debug/app-debug.apk (lesson 03) can be sent to a friend. They must allow installing from an unknown source on their phone. A debug APK is fine for testing, but it is not what you publish (lesson 49).

Android keeps a running system log. Everything that happens, from your own messages to system events to crashes, goes into it. Logcat is the tool that reads it. In Android Studio it is a window; on the command line it is adb logcat.

Logcat is the single most useful tool for finding out why something does not work, which is why lesson 18 (Debugging with Android Studio) and lesson 44 (Android Studio Power Tools) return to it. Today is your first look.

Open Logcat

Run your app on the emulator or phone, then choose View > Tool Windows > Logcat. Messages scroll by quickly. Scrolling up pauses the automatic scrolling; the Scroll to the End button resumes it. The toolbar also has buttons to clear, pause and restart the log.

Anatomy of one log line

A line looks like this (columns can be turned on or off in the view settings):

2026-10-18 10:15:32.123  4120-4120  LogLab   com.techbase.hellotechbase   D  Button tapped, count = 1

Priorities

From least to most serious:

A filter on a level shows that level and everything more severe.

Write your own messages

The Log class lives in android.util. Here is a complete screen that writes to Logcat each time you tap a button:

package com.techbase.hellotechbase
import android.os.Bundle
import android.util.Log
import androidx.activity.ComponentActivity
import androidx.activity.compose.setContent
import androidx.compose.foundation.layout.Arrangement
import androidx.compose.foundation.layout.Column
import androidx.compose.foundation.layout.fillMaxSize
import androidx.compose.foundation.layout.padding
import androidx.compose.material3.Button
import androidx.compose.material3.MaterialTheme
import androidx.compose.material3.Text
import androidx.compose.runtime.Composable
import androidx.compose.runtime.getValue
import androidx.compose.runtime.mutableIntStateOf
import androidx.compose.runtime.remember
import androidx.compose.runtime.setValue
import androidx.compose.ui.Alignment
import androidx.compose.ui.Modifier
import androidx.compose.ui.unit.dp
private const val TAG = "LogLab"
class MainActivity : ComponentActivity() {
 override fun onCreate(savedInstanceState: Bundle?) {
 super.onCreate(savedInstanceState)
 Log.d(TAG, "onCreate called")
 setContent {
 MaterialTheme {
 CounterScreen()
 }
 }
 }
 override fun onStart() {
 super.onStart()
 Log.i(TAG, "Screen is now visible")
 }
}
@Composable
fun CounterScreen(modifier: Modifier = Modifier) {
 var count by remember { mutableIntStateOf(0) }
 Column(
 modifier = modifier.fillMaxSize().padding(24.dp),
 verticalArrangement = Arrangement.Center,
 horizontalAlignment = Alignment.CenterHorizontally
 ) {
 Text(text = "Taps: $count")
 Button(onClick = {
 count++
 Log.d(TAG, "Button tapped, count = $count")
 if (count == 5) {
 Log.w(TAG, "That is a lot of taps")
 }
 }) {
 Text("Tap me")
 }
 }
}

Run it, then tap the button six times. This is what to look for in Logcat (timestamps and IDs vary, and extra system lines appear in between):

D/LogLab: onCreate called
I/LogLab: Screen is now visible
D/LogLab: Button tapped, count = 1
D/LogLab: Button tapped, count = 2
D/LogLab: Button tapped, count = 3
D/LogLab: Button tapped, count = 4
D/LogLab: Button tapped, count = 5
W/LogLab: That is a lot of taps
D/LogLab: Button tapped, count = 6

Compose details (remember, mutableIntStateOf, by) are explained in lesson 17 and lesson 19; today the point is the Log calls. The activity functions onCreate and onStart are part of the lifecycle taught in lesson 23.

The private const val TAG at the top is a good habit: one tag per file means you can filter easily. The tag should be a short stable name; very long tags are shortened by older Android versions.

Filter Logcat so you can see your messages

The unfiltered log has thousands of lines. The Logcat window has a query box at the top. Official queries use key:value pairs. Press Ctrl + Space in the box to see suggestions.

You can save and star favourite queries from the Show history button. If two apps are running or your phone is chatty, package:mine is the quickest way to cut noise.

Logcat on the command line

adb logcat # stream everything (Ctrl+C to stop)
adb logcat -d # dump what is in the log now, then exit
adb logcat -c # clear the log
adb logcat LogLab:D *:S # show tag LogLab at Debug and above, silence all others
adb logcat *:W # all tags, Warning and above
adb logcat -v time LogLab:D *:S # include date and time
adb logcat -d > mylog.txt # save the current log to a file

The filter form is tag:priority. The special *:S means "silence everything else", so only the tags you list appear. When you attach a bug report to an email or a forum post, adb logcat -d > mylog.txt is exactly what people ask for. Remember that logs can contain private information, so look through them before sharing.

Reading a crash

When an app crashes, Logcat shows the cause in red. Add this to your button code temporarily to see it:

if (count == 3) {
 error("Practice crash")
}

(error(...) is a standard Kotlin function that throws an IllegalStateException.) When you tap three times the app closes, and Logcat shows something like:

E/AndroidRuntime: FATAL EXCEPTION: main
E/AndroidRuntime: Process: com.techbase.hellotechbase, PID: 4120
E/AndroidRuntime: java.lang.IllegalStateException: Practice crash
E/AndroidRuntime: at com.techbase.hellotechbase.MainActivityKt.CounterScreen$lambda$...(MainActivity.kt:55)

Read it like a detective:

1. Find the line FATAL EXCEPTION. That is the start of the crash.
2. The next lines name the exception type (IllegalStateException) and message (Practice crash).
3. The indented at lines are the stack trace: where the code was. Find the first line that names your file and line number. In Android Studio it is a blue link you can click to jump to the exact line.
4. A Caused by: line further down is often the real root cause.

You can also filter with is:crash. When the app process restarts, Logcat prints PROCESS ENDED and PROCESS STARTED markers. Remove the crash line when you finish experimenting.

Logging cautions

• Never log secrets. Passwords, tokens and personal details written to Logcat can be read by anyone who connects to the phone with debugging on.
• Do not leave noisy logs in released apps. They cost battery and clutter the log. Many teams use a logging library or remove debug logs for release builds.
• Logcat is not permanent. The log buffer is small and old lines disappear. Save important output with adb logcat -d > file.txt soon after the problem.

Mistake #1: Using a charge-only cable. The symptom: the phone charges but adb devices shows nothing. The fix: try another cable, preferably the original one.

Mistake #2: Never accepting the RSA prompt. The symptom: the state is unauthorized. The fix: unlock the phone, replug, and tap Allow on the dialog. If it never appears, revoke USB debugging authorisations in Developer options and reconnect.

Mistake #3: Forgetting to turn on the main Developer options switch. The problem: the official docs warn that when the top-level toggle is off, most options are disabled. The fix: switch it on.

Mistake #4: Skipping the Windows driver. The symptom: the phone is not detected on Windows although everything else is right. The fix: install the phone maker's USB driver, then replug.

Mistake #5: Wireless pairing on a network that isolates devices. The symptom: the phone never shows up. The fix: use a home router or your own phone's hotspot, and make sure both devices are on the same network.

Mistake #6: Using a pairing port where a connect port is needed. The problem: adb pair uses the address shown on the pairing dialog; adb connect uses the different address on the main Wireless debugging screen. The fix: use each address for its own command.

Mistake #7: Typing "adb" and getting "command not found". The fix: adb lives in the SDK's platform-tools folder. Add it to your PATH or run it with its full path. Android Studio's Terminal tool window is a quick place to try.

Mistake #8: Hunting through unfiltered Logcat. The symptom: thousands of lines and no clue. The fix: use package:mine, tag:, and level: queries, and give your own messages a clear tag.

Mistake #9: Logging passwords and personal data. The fix: never log secrets. Anyone with debugging access can read the log.

Mistake #10: Ignoring the first line of a crash. The fix: start at FATAL EXCEPTION, read the exception type and message, and click the first stack-trace line that points to your own file.

Answer each question in your head (or on paper), then reveal the answer.

Question 1. How do you make Developer options appear on a phone?

Question 2. What are the three parts of adb, and which runs on the phone?

Question 3. adb devices shows unauthorized for your phone. What does it mean and how do you fix it?

Question 4. Write a Logcat query that shows only errors from your own app, and name the priority letter that Log.w uses.

Question 5. Why might adb install app-debug.apk fail when you have a phone and an emulator connected, and what are three ways to fix it?

Go deeper: official resources

• Android Basics with Compose, Unit 1: Set up Android Studio: the official pathway this lesson is based on.
• Run apps on a hardware device: USB and Wi-Fi connection, device mirroring and troubleshooting.
• Configure on-device developer options: enabling Developer options and USB debugging.
• Android Debug Bridge (adb): every adb command, including wireless debugging.
• View and write logs with Logcat: the Logcat window and its query syntax.
• Logcat command-line tool: adb logcat options and filters.