am start
唯讀用元件或 intent 啟動 Activity——這是驗證 deep link 能不能被接走最快的方法。
- 指令
- adb shell am start
- 指令
- 活動與 intent（am）
- 風險
- 唯讀
語法
am start [-W] [-a <action>] [-d <data URI>] [-n <package>/<activity>] [<extras>]旗標與參數
| token | 意義 |
|---|---|
| -W | 等啟動完成，並印出狀態與耗時。 |
| -a <action> | intent 的 action，例如 `android.intent.action.VIEW`。 |
| -d <uri> | intent 的 data URI。scheme 是必要的：沒有 scheme 就沒有東西可以和 intent filter 對上。 |
| -n <pkg>/<activity> | 直接啟動一個確切元件，跳過 intent 解析。 |
範例
am start -W -a android.intent.action.VIEW -d 'myapp://item/42'測一條 deep link，看是哪個 Activity 接走的。
am start -W -a android.intent.action.VIEW -d 'https://example.com/item/42'測 App Link，也能看出是不是瀏覽器贏了而不是你的 app。
am start -n com.example/.MainActivity直接啟動一個 Activity，完全不經過 intent filter。
輸出怎麼讀
輸出範例
Starting: Intent { act=android.intent.action.VIEW dat=https://example.com/ flg=0x10000000 }
Status: ok
LaunchState: COLD
Activity: com.example/.MainActivity
TotalTime: 245
WaitTime: 262
Complete加了 `-W` 會先看到平台解析後的 intent，再看到結果。真正有意思的失敗根本不是狀態行：`Error: Activity not started, unable to resolve Intent { … }` 是「沒人認領這個 scheme」的樣子，而 `Warning: Activity not started, its current task has been brought to the front` 是帶保留的成功——app 本來就開著，所以沒有冷啟動，也不會印出時間。
輸出欄位
| 欄位 | 意義 |
|---|---|
| Status: ok | 有 Activity 被啟動了。 |
| LaunchState | COLD、WARM 或 HOT——app 原本活著多少。 |
| Activity | 贏得這個 intent 的元件。 |
| TotalTime | 到 Activity 畫出來的毫秒數。什麼都沒啟動時不會出現。 |
| WaitTime | 包含呼叫方被擋住的時間的毫秒數。 |
| Error: … unable to resolve Intent | 手機上沒有人認領這個 intent。這常常正是你想測的答案。 |
需要什麼權限
一條授權過的 `adb` 連線。不用 root、不用 `su`，除了 USB 偵錯本身之外也沒有開發人員選項要開——啟動 Activity 本來就是 `shell` 使用者被允許做的事，這也讓它成為最便宜的 deep link 測試方法。限制是逐個元件而不是全域的：平台可以拒絕某一次特定的啟動，而拒絕會以 `SecurityException` 或 `Permission Denial` 的行出現，不是 `Status:` 那行。`parseAmStartResult` 專門盯這兩種形狀，並把裝置自己的句子原樣交還，因為那一行會自己說出理由，改寫它只會把唯一有價值的細節丟掉。加上 `-p <package>` 可以把啟動限縮到一個 app，這是好幾個 app 搶同一條連結時用來查出誰接走的方法；它不會多給你任何權限，也救不了一次被拒絕的啟動。
失敗訊息對照
| 訊息 | 意義 |
|---|---|
| Error: Activity not started, unable to resolve Intent | 寫在標準錯誤，後面接著平台組出來的那個 intent 原文。手機上沒有人認領這個 scheme，而對 deep link 測試來說，這通常正是你要的結果而不是故障。先讀大括號裡的內容：一個在沒加引號的 `&` 那裡被截斷的網址，解析出來的 intent 和你想測的那個不是同一個。 |
| Warning: Activity not started, its current task has been brought to the front | 帶保留的成功。app 本來就開著，所以它既有的 task 被拉到前面而不是冷啟動，`TotalTime` 與 `WaitTime` 都不會印。它們的缺席是關於這次啟動的事實，不是 0 毫秒的結果；想量冷啟動就先把 app 停掉。 |
| Status: timeout | 啟動被接受了，但 Activity 在 `-W` 等待的那段時間內沒有回報自己已經畫出來。app 十之八九在跑；失敗的是這次量測，所以在對那個沒出現的數字做任何解讀之前，先重做一次。 |
版本與廠商注意事項
- URI 要用單引號包起來。網址裡本來就會有 `&`，而沒有引號的 `&` 會把指令丟到背景並默默丟掉查詢字串的其餘部分——這是手打 deep link 測試「看起來沒反應」最經典的原因。
- 沒有 scheme 的 `-d` 什麼都不會啟動：intent 的 data 組不出來，也就沒有任何 filter 能對上。
- 只有真的啟動才會印出耗時，所以它的缺席是關於這次啟動的事實，而不是 0 毫秒。
這個我們有 UI
Android ADB Toolbox 會透過 USB 執行這個指令並解析回應——只要 Chromium 系瀏覽器，不必安裝 SDK，也不會上傳任何東西。
相關指令
和 am start 會在同一次作業裡出現的指令。
| 指令 | 做什麼 |
|---|---|
| am broadcast | 送出廣播 intent，這是從 shell 驅動 SystemUI demo mode 等平台接收器的方法。 |
| am force-stop | 殺掉屬於某個 app 的所有行程與服務。 |
| dumpsys activity activities | 現在哪個 app 在前景，以及它背後的 task 與 stack 結構。 |
這些行為是在撰寫 Web ADB 工具背後的解析程式時，對照 AOSP、toybox 與核心原始碼查證的。真的會因 Android 版本或廠牌而異的地方，這一頁會直接說明，而不是給你一個在半數手機上都是錯的數字。