DHIVA LABS · LEARN

Appearance

DroidDeck lab ​

Put the whole track to work on a device you own: connect it, install an app, watch that app's log while you use it, capture the screen, move a file both ways, go wireless with a pairing code, come back to USB, and leave the phone as safe as you found it.

Time: 45 to 60 minutes · Before this: lessons 1 to 5 of this track

What you need ​

  • A Linux computer with DroidDeck installed. Open it once and check that the adb card on the Devices tab shows a version and path.

  • An Android phone or tablet that you own, and a USB cable that carries data. For part 6 the phone needs Android 11 or newer, and must be on the same Wi-Fi network as the computer.

    No phone? An Android emulator from Android Studio works for parts 1 to 5. Skip part 6.

  • An APK you trust: one you built yourself, or one from the official release page of an open-source app. Check its SHA-256 checksum against the published value, as in lesson 5.

  • A small text file to copy to the phone. Create one in a terminal:

    bash
    echo "Hello from the DroidDeck lab" > ~/droiddeck-lab.txt

WARNING

Use a device that is yours, and do not uninstall, clear or delete anything you have not put there yourself during this lab. Every destructive action in DroidDeck is permanent.

Part 1: connect and authorise ​

  1. On the phone, turn on Developer options (tap Build number seven times in About phone), then turn on USB debugging in Developer options.

  2. Open DroidDeck on the Devices tab and plug in the phone.

    Expected: a card for the phone appears with the state unauthorized, and the right-hand panel asks you to accept the prompt on the device.

  3. Unlock the phone. Check that the prompt is for your computer, then select Allow. Tick Always allow from this computer only if this is your own computer.

    Expected: the state changes to online and the panel fills with System, Display, Battery and Network details.

  4. Write down the Android version and API level from System, and the IP address from Network. You will need the IP address in part 6.

Optional: in a terminal, run adb devices. The phone is listed with the state device, the word DroidDeck shows as online.

Part 2: install an APK ​

  1. Open the Apps tab and select Install APK. Choose your APK.

    Expected: a window titled Installing shows the output, and ends with a green tick and Installed. Select Close.

  2. With User selected, type part of the app's name in Search packages.

    Expected: the app's package name appears, such as org.example.app, with the path of its APK underneath.

  3. Copy the package name somewhere. Part 3 and the clean-up need it.

If the install ends with Failed, read the line above it. INSTALL_FAILED_UPDATE_INCOMPATIBLE means a copy signed with a different key is already installed: choose another APK rather than uninstalling an app you use.

Part 3: follow the app's log ​

  1. Open the Logcat tab.

    Expected: lines arrive straight away, coloured by priority, and the counter on the toolbar keeps rising.

  2. Type the package name into Package.

    Expected: the chip next to it reads not running, and the list is empty. The app is installed but has no process yet.

  3. Go back to Apps, open the app's Actions menu with the three dots, and select Launch.

    Expected: the app opens on the phone. Back on Logcat, the chip shows pid and a number, and the app's lines appear.

  4. Use the app for a minute: open screens, tap buttons. Watch new lines arrive. Select a long line to read it in full, then Close.

  5. Select W in V D I W E F.

    Expected: only warnings, errors and fatal lines from this app remain. A well-behaved app may show none at all. Select V again.

  6. On Apps, select Force-stop from the app's Actions menu, then Launch again.

    Expected: on Logcat, the chip shows not running for a moment, then a new pid number. The filter followed the app to its new process, which a fixed adb logcat --pid= command would not.

  7. Select Export current view to ~/Downloads.

    Expected: a message at the bottom gives the path of a droiddeck-logcat-…log file. Open it in a text editor and find the same lines.

Part 4: screenshot and screen recording ​

  1. With the app open on the phone, open the Screen tab and select Capture.

    Expected: the picture appears on the right, with the capture time and its size in pixels.

  2. Select Save… and save it. DroidDeck suggests a name starting with droiddeck and the device's serial.

  3. In Screen recording, choose 30 s and select Start.

    Expected: a red dot and a running timer.

  4. Scroll and tap around the app on the phone for ten seconds, then select Stop.

    Expected: Saving…, then a green tick and the path of an .mp4 file in your Videos folder. Select Open folder and play it.

Part 5: push and pull a file ​

  1. Open the Files tab. It opens in /sdcard. Select the Download folder.

  2. Select Push here and choose ~/droiddeck-lab.txt.

    Expected: the Transfers panel shows the file with a progress bar, then a green tick, and the file appears in the listing.

  3. Open the file's menu with the three dots and select Pull to ~/Downloads.

    Expected: a message reads Saved to and the path. Open ~/Downloads/droiddeck-lab.txt: it says Hello from the DroidDeck lab.

  4. Open the file's menu again and select Copy device path. Paste it into a note: /sdcard/Download/droiddeck-lab.txt.

Part 6: go wireless, then back to USB ​

Keep the cable plugged in for now.

  1. On the phone, open Developer options › Wireless debugging and turn it on. Allow it for this network only if it is your own.

  2. Select Pair device with pairing code. Leave that window open.

  3. In DroidDeck, open the Wireless tab. In Pair a device (Android 11+), type the phone's address and port into host:port and the six-digit code into pairing code, then select Pair.

    Expected: Paired — now connect using the port shown under Wireless debugging.

  4. On the phone, go back to the main Wireless debugging screen and read the IP address & Port. The port differs from the pairing port.

  5. Type that address into Connect by IP and select Connect.

    Expected: the phone appears a second time in the device list and the device picker, with a Wi-Fi icon. The address also appears under Saved devices.

  6. Unplug the cable. Select the Wi-Fi entry in the device picker, open Screen and select Capture.

    Expected: a screenshot arrives without the cable. Everything you did in parts 2 to 5 works the same way over Wi-Fi.

  7. On the phone, turn Wireless debugging off.

    Expected: the Wi-Fi entry is no longer online: it shows offline or leaves the list. In a terminal, adb disconnect followed by the address removes it for good. The pairing remains, so next time only steps 4 and 5 are needed.

  8. Plug the cable back in.

    Expected: the USB entry is online again, without a new prompt if you ticked Always allow in part 1.

You did not use Enable tcpip :5555 in this lab, on purpose. If you ever do, finish with Revert to USB, as lesson 3 explains.

Break it, try it ​

Each of these shows a failure on purpose, so you recognise it later.

  • Connect to the wrong port. Pair again, then type the pairing port into Connect by IP instead of the connect port. The connection fails. Compare with the FAQ: pairing and connecting always use different ports.
  • Use an old code. Close the pairing window on the phone, then select Pair with the code you wrote down. It fails, because the code only works while that window is open.
  • Take trust away. With the phone online over USB, open Developer options and select Revoke USB debugging authorizations. Unplug and replug. The state is unauthorized and the prompt returns. That is what every other computer that once had access now sees too.
  • Search the whole log. Empty Package, type the package name into Contains instead, and compare. You now see lines from the system about the app, such as the ActivityManager line when it starts, which the Package filter hides, and lose most of the app's own lines, whose messages rarely include its name.

Optional extension: point an app at a mock ​

If you have Mock Studio, watch the same request from both ends: Mock Studio's Live log on the computer and logcat from the phone.

  1. Open a Mock Studio project, such as the one from Your first mock server, and select Start server.

  2. Select Share and find the right address for the device:

    • a phone on the same Wi-Fi: the address in Local network (LAN), such as http://192.168.1.20:8080;
    • an emulator on this computer: http://10.0.2.2:8080, because localhost inside the emulator means the emulator itself.

    Use your own port in place of 8080.

  3. On the phone, open the browser and go to that address plus an endpoint path, such as /health.

    Expected: the mock's reply in the browser, and the request in Mock Studio's Live log. If the phone cannot connect, check the computer's firewall and see If a device cannot connect.

  4. If you build your own app, set its API base URL to the same address and use it, with the Package filter on in DroidDeck's Logcat.

    Expected: each call shows in Live; any error your app logs shows in logcat at the same moment.

Good to know

Android blocks plain http:// traffic by default in apps that target Android 9 or newer, and the mock serves http:// on the LAN. If your app's calls fail and logcat mentions that cleartext traffic is not permitted, allow cleartext traffic in your app's debug build only, never in a release build. Browsers are not affected by this.

TIP

Instead of the LAN address, you can carry the mock over the USB connection. In a terminal, adb reverse tcp:8080 tcp:8080 makes http://localhost:8080 on the phone reach port 8080 on your computer. adb reverse --remove-all undoes it.

Stop the server in Mock Studio when you finish: while it runs, any device on the network can reach it.

Clean up ​

  1. Remove the test app, if you do not want to keep it: Apps › the app's Actions menu › Uninstall… › Uninstall. Check the package name in the question first.

  2. Delete the test file from the phone: Files › Download › droiddeck-lab.txt › Delete… › Delete.

  3. Remove the pairing if this is not your everyday computer: on the phone, Wireless debugging › Paired devices, select the computer, and forget it.

  4. Revoke and switch off. If you connected to any computer that is not yours, select Revoke USB debugging authorizations. Then turn USB debugging off, or Developer options off altogether.

  5. Tidy your computer. The screenshot, recording, log export and pulled file are in the folder you chose, ~/Videos and ~/Downloads. They may show notifications or personal data; delete the ones you do not need.

Check yourself ​

QuizDroidDeck lab

Question 1 of 6

You type the package name into Package on the Logcat tab and the chip reads not running. What do you do?

Score: 0

What you learned ​

  • Connecting is two steps: USB debugging on, then the computer authorised; only online devices can be used.
  • DroidDeck's Package filter follows an app's log across restarts, and an export saves what the filters show.
  • Pairing uses one port and a short-lived code; connecting uses another port that can change.
  • Every change you make for a test, from wireless debugging to a pushed file, has a matching clean-up step.

Next steps ​