Android Photo Transfer

關於這個工具

把 Android 用 USB 接上 Chromium 系瀏覽器，這頁就能讀它的儲存空間：相簿與其他媒體資料夾，依每個檔案的拍攝日期分組，大小與日期直接來自檔案系統。勾好要的東西，它會一邊組一邊寫進磁碟成為 ZIP，或是一個一個存下來。同一頁也能一層一層翻手機其他目錄，並把檔案往反方向送回去。手機上不會安裝任何東西，也不會上傳到任何地方——這只是一個靜態頁面透過線材跟 adbd 對話，關掉分頁就結束了。

為什麼抓照片用 ADB 比 MTP 可靠

把手機接上電腦、選「檔案傳輸」時走的是 MTP——2008 年為相機設計的協定，每一次檔案操作都要跟手機維護的資料庫來回一趟，而且沒有真正的檔案 handle。實際結果就是大家都很熟的那些症狀：資料夾顯示的張數不對、複製 3000 個檔案到 1700 個就無聲停住、縮圖把檔案總管卡死、同一條線同一批位元組的影片速度只有 ADB 的十分之一，還有非得拔插一次電腦才重新看得到手機。ADB 的 sync 協定小得多：開一條串流、講一個路徑、收位元組。它讀的是檔案系統而不是媒體資料庫，所以列出來的就是真的在那裡的東西；失敗時它會指名是哪個檔案失敗，而不是整批停下來。

scoped storage 並不會擋 shell 讀 DCIM

從 Android 11 起，*app* 沒有特殊權限就讀不到共用儲存空間裡其他 app 的檔案，這也是為什麼很多檔案管理與備份 app 變難用。但 ADB shell 不是 app：它以 shell 這個使用者身分執行，對主要共用磁碟區握有很大的讀取權限，所以 /sdcard/DCIM、/sdcard/Pictures、/sdcard/Movies、/sdcard/Download 透過線材讀起來跟以前一樣。這頁能成立就是靠這件事。scoped storage 真正關上的那扇門是 /sdcard/Android/data，也就是 app 自己的私有檔案——那不是這頁在讀的地方；Storage Analyzer 有去碰的時候，也明白寫著 shell 在那裡讀不讀得到會隨版本與廠牌而異。

streaming ZIP 是什麼，為什麼不能在記憶體裡組

相簿動輒幾十 GB。任何「全部打包下載」卻先在瀏覽器把檔案收起來的做法，等於默默承諾要把全部塞進分頁的記憶體，遇到真手機就不可能撐住。所以這裡的做法是反過來的：照片以小塊從手機讀出，每一塊直接進壓縮編碼器，編好的每一塊又直接寫進你在傳輸開始前指定的磁碟檔案。不管總量多少，尖峰記憶體都只有幾百 KB。這個設計在畫面上留下兩個痕跡。壓縮檔是**儲存**而非壓縮——JPEG 與 H.264 本來就壓過了，再 deflate 一次只是花手機的時間換不到 1% 的縮減。另外，傳統 ZIP 的大小與位移都是 32 位元欄位，所以超過大約 4 GB 的選取會切成編號的多份，而不是變成「這台電腦打得開、換一台就說壞檔」的壓縮檔；單一檔案大到任何壓縮檔都裝不下時，就以原本的檔名寫在旁邊。要直接寫磁碟得靠 File System Access API，它只有 Chromium 系有，而且必須在點擊時詢問存放位置；沒有的時候這頁會改成一個一個存並講清楚，而不是偷偷改成在記憶體裡組 ZIP。

縮圖真的會吃傳輸量，所以預設關閉

手機上沒有這頁能用的縮圖：Android 把自己的預覽放在 app 私有的快取裡，shell 碰不到，而 sync 協定也沒有辦法只要一張解碼後圖片的一部分。所以「預覽」就等於把原檔整張拉過來——1200 萬像素一張 3 到 5 MB，4800 萬像素超過 10 MB，一個畫面十二張就是幾十 MB 走過那條線。因此相簿一開始就是關圖片的省流模式，捲到可視範圍才載入、同時最多三張、絕不預先抓、對已解碼縮圖保留量設上限，並持續顯示預覽到目前為止花掉多少。HEIC 會列出來但不預覽，因為桌面瀏覽器解不了那個格式。

這頁不會刪掉手機上任何東西。這套工具的刪除歸 Storage Analyzer 負責，而且只限它的掃描器找出來的目標——這裡沒有自由路徑刪除，也沒有任何路徑能走到那裡。相對地，把檔案送上手機確實改變了手機，所以它走的是這一家族同一套警告級確認，寫入之前先把確切的目標路徑一條條列出來。從這裡往下走：Web ADB 首頁有裝置儀表板與其他工具，Storage Analyzer 告訴你是什麼佔滿了手機，APK Installer 則負責把軟體往反方向送。