英語版で読む
技術約17分で読めます

Xperia Z3 Tablet CompactにLineageOS 18.1を入れてみた

AndroidWindows実験
いけさん目次

古いXperia Z3 Tablet Compactを、自宅サーバーにつながる表示端末として使いたい。
画像生成やセンサーデータの集計はサーバー側でやって、タブレットには画像やCO₂などの情報を表示させるつもりでいる。

電源を入れてみると、基本操作は意外ときびきびしていて、Wi-Fiにもつながった。ただ、Google Playストアのエラーがことあるごとに出る。
純正Androidのまま表示だけさせる案も考えたが、これでは実用にならないので、OSを書き換えることにした。

作業した環境

項目内容
PCWindows 11 Home
ADB以前入れたAndroid SDKのplatform-tools（Version 36.0.0-13206524）
Python3.14
PowerShell7.6.6
端末Xperia Z3 Tablet Compact SGP611（Wi-Fiモデル）
導入したOSLineageOS for microG 18.1（2026年4月10日ビルド）

ADBはUSB経由でAndroid端末にコマンドを送るツールで、PATHには通っていなかったが、以前入れたAndroid SDKに残っていたので、そのまま使った。

& "$env:LOCALAPPDATA\Android\Sdk\platform-tools\adb.exe" version
Android Debug Bridge version 1.0.41
Version 36.0.0-13206524

ブートローダーを解除できるかの確認

最初はChatGPTと相談して、Android 11ベースのLineageOS 18.1（Android端末向けのオープンソースのOS）を候補にした。
Google Appsを入れず、ブラウザ中心の軽い構成にするつもりだった。

OSを書き換えるには、先にブートローダー（OSより前に動いて起動を管理するプログラム）のロック解除がいる。解除できる個体かどうかは、サービスメニューの Bootloader unlock allowed に出る。

ChatGPTの最初の回答は、Wi-Fi専用のタブレットなのに電話アプリからサービスコードを入力させるもので、これは間違いだった。
後から連絡先アプリ経由の方法に訂正され、Bootloader unlock allowed: Yes（解除してよいという許可の表示）まで確認できた。Sonyのブートローダー解除ページにも、連絡先アプリの設定画面からサービスコードを入力する手順が載っている。

ADBで端末が認識されない

& "$env:LOCALAPPDATA\Android\Sdk\platform-tools\adb.exe" devices -l

最初は List of devices attached の後が空だった。
Android端末のUSB接続には、ファイル転送用のMTPとADB用の通信が別々にある。Windowsでは機種名SGP611のMTP USBデバイスとしてだけ認識されていて、ADB用の接続は出ていなかった。

確認した時点USB IDWindowsでの認識
最初VID_0FCE&PID_01C0MTPのみ、wpdmtp.inf
ADBでつながったあとVID_0FCE&PID_51C0MTPの MI_00 とADBの MI_01

端末側の開発者向けオプションと接続の許可を確認してから再実行すると、ADBでも device になった。
PC側ではドライバを追加しておらず、ADB側はWindows標準の winusb.inf で認識された。

端末の型番とビルド番号

ADBで型番やビルド番号を取得した。

項目値
型番SGP611
Android6.0.1
セキュリティパッチ2016-05-01
ビルド番号23.5.A.1.291
CPU ABIarmeabi-v7a
暗号化状態unencrypted
カスタマイズ1290-3028 / R3D

ro.boot.verifiedbootstate と ro.boot.flash.locked は空で、ここからはブートローダーの解除状態を確かめられなかった。

純正AndroidのGoogle Playストアのエラー

端末情報の画面を開いてスクリーンショットを撮ったら、ちょうどGoogle Playストアのエラーが出ていた。

純正Android 6.0.1でGoogle Playストアの終了ダイアログが出たSGP611

OKを押してダイアログを閉じると、SGP611とAndroid 6.0.1の端末情報が出た。

エラーダイアログを閉じた後のSGP611の端末情報

ビルド番号を撮ろうとしてスクロールしたところで、また同じエラーが出た。

スクリーンショットは adb -d exec-out screencap -p の出力を、PowerShellの文字列変換を通さないよう、Pythonでバイナリのまま保存した。

MOTO+4のSGP611導入記録

SGP611でLineageOSを入れた先例として、MOTO+4の導入記録があった。LineageOS 18.1のmicroG版を入れていて、microGはGoogleのアプリやライブラリの機能をオープンソースで作り直したもの。
ただ、この記録ではROMのインストールスクリプトにある機種チェック（書き込む端末が対応機種かをインストール時に確かめる処理）を外し、Google Appsも追加していた。

そこで、機種チェックを外さずに入れられる配布ファイルを探した。

LineageOS for microG 18.1の配布ファイル

LineageOS for microGのSGP611向け配布先に、2026年4月10日ビルドのROMと、同じビルドのboot・recoveryイメージがあった。
bootはOSを起動するためのイメージ、recoveryはOSの導入や初期化に使う環境のイメージで、どちらもパーティション（ストレージの区画）に書き込んで使う。

ファイルサイズ
lineage-18.1-20260410-microG-z3tcw.zip640,987,602バイト
lineage-18.1-20260410-microG-z3tcw-boot.img8,040,448バイト
lineage-18.1-20260410-microG-z3tcw-recovery.img14,647,296バイト

同じプロジェクトにはmicroGを含まない版の配布先もあるが、その一覧に z3tcw はなかった。
ブラウザ中心で使うので、Google PlayストアやGApps（Googleアプリ一式）は追加せず、配布プロジェクトの説明にある構成のまま使うことにした。

3ファイルとも、配布元が公開しているSHA-256（ファイルの中身から計算する値）と同じ値だった。

ROMの署名検証とメタデータ

導入Wikiには、ROMのZIPに配布元の署名が付いているかを確かめる手順もある。
公式の update_verifier を取ってきて、まずは付属のrequirements.txtどおりにパッケージを入れようとした。

git clone --depth 1 https://github.com/lineageos4microg/update_verifier.git .tools/update_verifier
python -m venv .tools/verifier-venv
.tools/verifier-venv/Scripts/python.exe -m pip install -r .tools/update_verifier/requirements.txt

このPCのPython 3.14では、指定されていた cffi==1.17.1 のビルド済みパッケージ（wheel）が使われず、C++のビルド環境を求められてインストールに失敗した。
検証スクリプトはそのままにして、Python 3.14用のwheelがあるパッケージを同じ仮想環境に入れ直した。

.tools/verifier-venv/Scripts/python.exe -m pip install --only-binary=:all: asn1crypto==1.5.1 cryptography

asn1crypto 1.5.1、cryptography 50.0.2、cffi 2.1.1、pycparser 3.11 が入り、これで公開鍵を使った署名検証が通った。

verified successfully

ROM内の pre-device（対象機種の一覧）には z3tcw,scorpion_windy,SGP611,SGP612 が書かれていて、インストールスクリプトの機種チェックにもSGP611が含まれていた。ZIP内の boot.img も、別に配布されているbootイメージと同じファイルだった。

ファイル名の2026年4月10日はビルド日で、ROMのメタデータにある post-security-patch-level は2024-02-05、post-sdk-level はAndroid 11のAPIレベルに当たる30だった。

DRMキーとTA領域のバックアップ

かなり前の端末で大したデータは入っていないので、写真や壁紙は引き継がずに初期化することにした。
ただ、Sonyの端末にはDRMキー（著作権保護機能などに使う端末固有の鍵）があり、写真などとは別のTA領域に入っている。

Sonyの公式説明では、ブートローダーを解除すると初期化され、DRMキーも元に戻せないとしている。
ADBからTA・boot・FOTAKernelのパスにアクセスしようとしたが、ADBシェルにroot権限がなく Permission denied になり、TA領域のバックアップは取れなかった。

Sony公式の解除コード

ADBで取得できる ro.boot.idid は、14文字のIDID（端末の識別番号）だった。Sonyの解除コードのフォームは、IMEIの代わりにこのIDIDでも受け付ける。

フォームでは機種をXperia Z3 Tablet Compactにして、IDIDを入れた。保証に関する2項目にチェックを付けてSubmitを押し、画像認証は手で済ませた。コードをもらうのにメールを送る手順はなかった。

Fastbootで端末が出てこない

解除コマンドは、Fastboot（PCからブートローダーに書き込みや起動を指示するモード）で送る。
ところが、端末をFastbootで再起動すると、今度は端末一覧が空になった。

adb -d reboot bootloader
fastboot devices

Windowsには S1Boot Fastboot が出ていて、USB IDは VID_0FCE&PID_0DDE、問題コード28で、対応するドライバが入っていなかった。

Sony公式の機種別ドライバを取ってきて中身を調べると、署名は有効だった。
ただ、INF（ドライバが対応する機器を書いた設定ファイル）にはADB用のIDしかなく、Fastboot側の PID_0DDE は含まれていなかった。

Windows標準の winusb.inf にはMicrosoftのADB用の定義があり、WinUSB.sys の署名も有効だった。
そこで、このWinUSBドライバを、接続中のSonyのFastbootインターフェースだけに割り当てることにした。INFは書き換えず、WindowsのDiInstallDevice APIで、Windowsに入っているドライバをこの機器に割り当てた。

対象を接続中の1台のUSB IDに絞ったスクリプトを作り、まずはドライバを適用しないモードで候補を出してみた。
最初は候補が出ず、非表示のPnPドライバも列挙するオプションを追加した。
さらに、スクリプトが英語の ADB Device という名前で候補を探していたため、日本語版Windowsの ADB デバイス に当たらず、判定を直した。直したあとは候補が出た。

Available: Microsoft / ADB デバイス; no driver installed.

管理者権限でのドライバ適用

適用には管理者権限がいる。
最初にUAC（管理者権限を求めるWindowsの確認画面）付きの別プロセスを起動したときは、Windowsから「ユーザーによって取り消されました」と返ってきて、適用されなかった。

通常権限で開いたPowerShell 7.6.6から適用コマンドを実行しても、スクリプトの管理者チェックに引っかかり、次のエラーが返ってきた。

Driver installation requires an elevated PowerShell process.

原因はPowerShellの版ではなく、起動したプロセスの権限だった。もう一度UAC確認付きの別プロセスを起動し、同じスクリプトを実行した。

Start-Process -FilePath 'C:\Program Files\PowerShell\7\pwsh.exe' `
  -Verb RunAs -WindowStyle Hidden `
  -ArgumentList @('-NoProfile', '-File',
    '<作業フォルダ>\scripts\Install-FastbootDriver.ps1',
    '-Install') -Wait

今度は適用でき、PCの再起動もいらなかった。

Installed: Microsoft / ADB デバイス; restart required: False

S1Boot Fastboot の問題コードが消えて fastboot devices に端末が出るようになり、fastboot getvar product も SGP611 を返した。
一方で getvar unlocked は空欄で、bootとFOTAKernelのサイズ・種類も空欄だった。fastboot oem device-info は15秒応答がなく、タイムアウトした。

recoveryの書き込み先

取ってきたrecoveryイメージを展開して、system/etc/recovery.fstab の中身を確認した。

/dev/block/bootdevice/by-name/boot        /boot       emmc
/dev/block/bootdevice/by-name/FOTAKernel  /recovery   emmc

このビルドでは /recovery が FOTAKernel に割り当てられていて、recoveryを書き込むなら書き込み先はFOTAKernelになる。

recoveryの一時起動でUSBから消えた

パーティションには書き込まず、まずrecoveryを一時的に起動できるか試した。

fastboot boot downloads/lineage-18.1-20260410/lineage-18.1-20260410-microG-z3tcw-recovery.img
Sending 'boot.img' (14304 KB) OKAY [0.503s]
Booting FAILED (Status read failed (Too many links))
fastboot: error: Command failed

送信はできたが、起動結果を受け取るところで失敗し、端末がUSBから消えた。ADBとFastbootの一覧はどちらも空になった。

この時点では、電源が落ちたのか、起動に失敗して止まったのか区別がつかなかった。
9分ほどあとに確認すると、MTPとADBが出てきて、元の純正Androidが起動していた。

項目取得した値
機種SGP611
Android6.0.1
ビルド23.5.A.1.291
起動完了sys.boot_completed=1

これ以降は実機に触らない条件にして、PCからだけ操作した。
サービスメニューもADBから開き、出ていたエラーダイアログもADBのタップ操作で閉じた。途中ではGoogle Playストアのほかに、Sonyのカメラアプリのエラーも出た。

Service info → Configuration で Bootloader unlock allowed: Yes をもう一度確かめ、ROM・boot・recoveryのSHA-256も確認し直した。

ブートローダーの解除

初期化されてDRMキーが元に戻らないことも承知のうえで、Sony公式の解除コードで解除した。
送る前に、接続中の端末のシリアル番号が事前に控えた値と同じか、Fastbootの product が SGP611 かを確かめた。

adb -d reboot bootloader
fastboot oem unlock 0x<端末固有の解除コード>

解除コマンドには OKAY が返り、所要は5.924秒。

Lineage Recoveryの起動

recoveryの置き場所はFOTAKernelだが、まずはrecoveryを起動するため、recoveryイメージをboot領域に書き込んだ。
このboot領域は、あとでROM本体のZIPを入れるとOS用のbootイメージで上書きされる。

fastboot flash boot downloads/lineage-18.1-20260410/lineage-18.1-20260410-microG-z3tcw-recovery.img
fastboot reboot

送信も書き込みも OKAY で、再起動するとADBに recovery として接続できた。
USB IDは VID_18D1&PID_D001 に変わったが、Windowsはドライバを追加せずに認識した。画面もLineage Recovery 18.1になっていた。

SGP611で起動したLineage Recovery 18.1

recoveryのADBシェルはroot権限で、ro.product.device は z3tcw、Lineageのバージョンは 18.1-20260410-microG-z3tcw が返ってきた。Androidのバージョンも11と返ってきたが、これはrecovery側の値。

recoveryをPCから操作する

純正Androidで使った screencap や input は、recoveryには入っていなかった。
画面は /dev/graphics/fb0（画面の画素データが入ったフレームバッファ）から読み出し、PNGに変換して保存した。

フレームバッファは幅1200、メモリ上の縦幅3840で、1920pxの画面2枚分になっている。1行あたりのバイト幅（stride）は4864、32bitのRGBAだった。
片方の画面が黒いままだったり前のメニューのままだったりすることがあったので、両方を保存して中身を確かめた。

操作は sendevent で音量キーと電源キーの入力を送った。
この端末では、音量キーが /dev/input/event4、電源キーが /dev/input/event2 だった。

dataとcacheの初期化

recoveryの Factory reset → Format data/factory reset を開き、確認画面で Format data を、PCからのキー入力で選んだ。

ログでは /data がF2FS、/cache がext4（どちらもファイルシステムの種類）で作り直され、最後に Data wipe complete. が出た。

dataとcacheの初期化完了を示すLineage Recoveryの画面

FOTAKernelへのrecovery書き込み

書き込む前に、FOTAKernelの元の中身をPCへ読み出して保存した。バックアップできたのはこの16MiBのパーティション分だけで、解除前のTA領域や純正ファームウェア一式は取れていない。

あとでPCからrecoveryに入れるよう、FOTAKernelにも同じrecoveryを書き込んだ。

adb -d reboot bootloader
fastboot flash FOTAKernel downloads/lineage-18.1-20260410/lineage-18.1-20260410-microG-z3tcw-recovery.img
fastboot reboot

こちらも OKAY で、1.517秒で書き終わった。

sideloadが途中でエラーになった

recoveryに戻って Apply update → Apply from ADB を開き、署名を確かめたZIPを手を加えずにsideload（recoveryにADBでZIPを送って入れる方法）で送った。

adb -d sideload downloads/lineage-18.1-20260410/lineage-18.1-20260410-microG-z3tcw.zip

日付が変わって10月19日の0時ごろ、PC側の表示は47%で止まり、コマンドは終了コード1で終わった。

adb: failed to read command: No error

ところが、recoveryにADBでつなぎ直して端末側のログを確認すると、インストール自体は成功していた。
署名検証は通っていて、パッケージ検証の結果は 48.8 s (result 0)。画面にも script succeeded: result was [1.000000] と出ていた。

ROMの署名検証とインストールスクリプトの成功結果

ログでは、systemに書いたブロック数と予定のブロック数がどちらも 378971 で、インストールには152秒かかり、再試行は0回だった。

PC側の終了コードとは結果が食い違うので、boot領域をPCへ読み出し、配布されているbootイメージと同じ長さの部分をSHA-256で比べた。
FOTAKernelも同じ方法で比べ、どちらも配布ファイルと同じだった。

systemを読み取り専用でマウントすると、ファイルは /mnt/system/system/ の下にあった。
最初は /mnt/system/app を開こうとして失敗し、パスを直してbuild.propとアプリ一覧を確認できた。

build.propではAndroidが11、Lineageが 18.1-20260410-microG-z3tcw になっていた。
systemの中には、Jelly（LineageOS標準のブラウザ）、webview、GmsCore（microGの本体）、FakeStore（Playストアがあるように見せる代わりのアプリ）のディレクトリがあった。

初回起動後もPCから接続できるよう、PCのADB公開鍵を初期化後のdataに置いて、0時2分59秒に再起動した。

Android 11の初回起動

0時4分2秒に、起動完了を示す sys.boot_completed=1 になった。再起動を送ってから約63秒。

項目起動後の表示
モデルXperia Z3 Tablet Compact Wifi
Android11
Lineage18.1-20260410-microG-z3tcw
セキュリティパッチ2024-02-05

画面もLineageの初期設定になっていた。

Android 11の通常起動後に表示されたLineageの初期設定画面

初期設定の途中で画面が黒くなり、ADBから送ったスワイプが反映されなくなった。
電源の状態を確認すると、60秒のタイムアウトで画面が消えていただけで、電源は入ったままだった。

最初は svc power stayon usb でUSB給電中は画面を消さないようにしたが、このROMではPCとの接続がAC給電として扱われていた。
stay_on_while_plugged_in をACとUSBの両方を含む3に変え、画面を点けるキーを送ると、操作が反映されるようになった。

日本語での初期設定

言語の選択リストをADBからフリックしても、リストからは日本語を選べなかった。
ADBから言語とタイムゾーンを指定し、Androidアプリの元になるプロセス（zygote）を再起動すると、初期設定も日本語で表示された。

adb -d shell settings put system system_locales ja-JP
adb -d shell setprop persist.sys.locale ja-JP
adb -d shell cmd alarm set-timezone Asia/Tokyo
adb -d shell setprop ctl.restart zygote

Wi-Fi専用のSGP611でも「SIMカードがありません」と出たが、そのまま次へ進めた。
Wi-Fiの設定はここでは飛ばし、位置情報と診断データ送信を無効にして、画面ロックとデータ復元はスキップした。

完了フラグの user_setup_complete=1 と device_provisioned=1 が立ち、ホーム画面も日本語で表示された。
時計はROMのビルド日の2026年4月10日のままだったので、PCの現在時刻を cmd alarm set-time で設定して日本時間に合わせた。

バージョン画面でも、OS本体の情報を確認した。

日本語設定で表示したAndroid 11とLineageOS 18.1のバージョン情報

Android側のセキュリティパッチは2024年2月5日で、ベンダー側は純正のときと同じ2016年5月1日だった。

Google Playストアのパッケージ名 com.android.vending の中身は、FakeStore.apk だった。

Jellyでテストページを表示

標準ブラウザのJellyで、ページを表示できるか確かめた。PCのlocalhostにテスト用のHTMLとJSONだけを置き、adb reverse（端末からPC側のポートへ転送する機能）で端末から開いた。

adb -d reverse tcp:<ポート> tcp:<ポート>
adb -d shell am start -a android.intent.action.VIEW -d http://127.0.0.1:<ポート>/ -p org.lineageos.jelly

日本語のページが表示され、JavaScriptでの時刻更新とJSONの取得もできた。
PC側のテスト用サーバーのログでも、HTMLとJSONへのリクエストはどちらもHTTP 200（正常応答）だった。

JellyでHTTPとJavaScriptとJSON取得を確認したテストページ

再起動とロック画面

OS本体から adb reboot recovery を送ると、boot領域を書き直さなくても、先にFOTAKernelへ書いておいたLineage Recoveryに入れた。
そこから adb reboot でOS本体に戻し、起動完了まで確認した。

項目再起動後
言語日本語
タイムゾーンAsia/Tokyo
初期設定完了のまま
時計PCとの差は約-0.5秒
給電中に画面を消さない設定有効のまま
電池100%、31.3℃
WebView（アプリ内でWebページを表示する部品）146.0.7680.153
crashバッファの FATAL EXCEPTION（アプリが異常終了した記録）再起動前後とも0件

ただ、PINを設定していないのに、再起動後はスワイプで解除するロック画面が出た。
実機に触らずにホーム画面を出せるよう、ロックをなしにした。

adb -d shell locksettings set-disabled true
adb -d shell wm dismiss-keyguard

もう一度再起動すると、今度はロック解除の操作を送らなくても、PCからAndroidのバージョン画面を開けた。

Wi-Fiの接続

Wi-Fiをつないだあと、端末の状態をPCから確認した。

adb -d shell dumpsys wifi
adb -d shell ip -4 addr show wlan0
adb -d shell ip -4 route
adb -d shell ip -4 route show table all
adb -d shell dumpsys connectivity

wlan0（Wi-Fiのネットワークインターフェース）にはIPv4アドレスが割り当てられていて、ネットワーク状態は CONNECTED。Android側でインターネット接続を確認済みという印の VALIDATED も付いていた。

最初の ip -4 route ではデフォルト経路（外へ出るときの経路）が出なかったが、全テーブルを表示すると wlan0 のデフォルト経路が見つかった。