Gradle / Build Variant / Install / Logcat / ADB：失敗到底在哪一層？

Learning outcomes

• 能畫出 source → Gradle → APK → install → process。
• 能區分 build failure、install failure、runtime crash、permission/data failure。
• 能用 Logcat / ADB 蒐集基本 evidence。
• 能理解 debug / release variant 可能行為不同。

1. Build pipeline

Gradle 是 build system，不是 Android runtime。

2. Build variant

debug
release

不同 variant 可能有不同 signing、minification、build config、backend endpoint、logging。Debug 能跑不代表 Release 一定等價。

3. Build failure

例如 dependency resolution、Kotlin compile、resource linking、manifest merge，都可能在 app 還沒安裝前就失敗。

4. Install / launch failure

adb devices
adb install app-debug.apk

裝置是否連線、授權、storage、package/signature conflict 都屬不同層。

5. Logcat：runtime evidence stream

adb logcat

Logcat 可能包含：

• app crash stack trace
• permission/security exception
• system lifecycle messages
• 你自己的 structured logs

真正 debug 時要用 package/process/tag/filter 縮小範圍，不是從幾萬行裡瞎找。

6. ADB：電腦和 device 的控制/觀察通道

adb devices
adb shell
adb logcat
adb install ...

ADB 能操作很多低階功能。只執行你理解的 command，尤其避免破壞性 shell 操作。

7. Trip Meter 的 debugging evidence

Build
  → Gradle task result

Install
  → adb / Android Studio deploy output

Launch
  → process exists?

Permission
  → permission state/result

Location
  → timestamp / accuracy / provider

Domain
  → accepted sample / distance delta

UI
  → rendered TripScreenState

把 evidence 分層後，「手機上數字不動」才能從模糊現象變成可定位問題。

8. Project checkpoint：Trip Meter Android Shell v3

最終 architecture：

Android UI
   ↓ user intent
ViewModel
   ↓
permission state
   ↓
location provider
   ↓ LocationSample
Trip domain / repository
   ↓ TripState
ViewModel StateFlow
   ↓
UI

Build path:
source
 → Gradle
 → APK
 → install
 → app process
 → Logcat evidence

9. 107–112 最後真正學到什麼？