気の向くままに辿るIT/ICT/IoT
ハードウェア

Raspberry Pi 400にWaydroidでLineageOS 18.xベースAndroid 11

ホーム前へ次へ
Raspberry Piって?

Raspberry Pi 400にWaydroidでLineageOS 18.xベースAndroid 11

Raspberry Pi 400にWaydroidでLineageOS 18.xベースAndroid 11

2023/05/14
arm64なRaspberry Pi 400/Raspberry Pi OSにWaydroidでLineageOSベースのAndroid

 先日、DebianにWaydroidで爆速快適なAndroidを体験、そりゃ、今やメインのRaspberry Pi 400にも入れなっくちゃでしょということでWaydroid安定版で最新のLieageOS 18.xベースAndroid 11相当を入れてみた話。

 というか、そもそもRaspberry Pi 400に入れようと思ってたのですが、標準では未対応、カーネルビルドしないといけないっぽいというわけで先にその必要のないDebianで試してみることに。

 元々したかったことはできないことが判明したものの、これまでのエミュレータではあり得ない、あまりの快適さに早くやってみたくなりました。

 そこで練習としてUSBメモリに入っていたRaspberry Pi OS向けにカーネルオプションを追加し、Raspberry Pi 400でカーネルをクロスコンパイル、できた後、USBメモリを起動してWaydroidもインストール、wayland initもできた...。

 までは良かったのですが、Waydroidの起動確認をすべく、WaylandベースのデスクトップがあるGNOMEをインストール中、容量不足でどうにもならなくなり...。

 ちょっとやる気が失せて気分を切り替えるべく、他の作業をあれこれやってる内、さてやってみるかと思えたのが今日だったと。

arm64/aarch64 Raspberry Pi OSカーネルのビルド

arm64なRaspberry Pi 400/Raspberry Pi OS/Waydroidのアプリ一覧画面

 インストールや使い方、制限・制約や、ちょっと困った点など詳細は冒頭リンク先のDebianのページを参照ください。

 ただ、Raspberry PiでWaydroidを動かすためには、現時点、Raspberry Pi OSでは無効になっているというLinuxカーネル 4.20で導入されたPSI/Pressure Stall Informationを有効にする必要があるとのこと。

 コマンドラインオプションとしてpsi=1を渡すという情報は、そこそこあり、Raspberry Pi OSにおいては、cmdline.txtに追記しても有効にならないという情報がちらほら。

 一方、カーネルのビルドオプション[CONFIG_PSI]を有効にすべく、[CONFIG_PSI=y]する必要があるという情報は極端に少ないんですよね、国内外問わず。

 まして、それどこで設定するのって情報は、皆無に近いという...が、これは有力情報でしょというか、それが解でしょ。

 というわけでThe Linux Kernel by raspberrypi.comの手順通りにカーネルをビルド。

 途中、make ***_defconfigすると[.config]ファイルができるので、これに先のビルドオプションを設定してmakeでビルド。

 ビルド開始直後、すぐに「PSIを有効にするにあたり、ブートオプション指定を必要とするか否か」の旨、問われるので好きにするだけ。

 自身はデフォルトのNにしましたが、たぶんyにするとRaspberry Pi OSの場合、cmdline.txtにpsi=1を追記する必要が生じて初めてその設定が効いてくるのでしょうね。

 あとページのほとんどの画像の端末上のuname -a結果に見てとれるように自身は[CONFIG_LOCALVERSION]も設定しましたが。

 ビルド時間については、Raspberry Pi 400でローカルビルドが約110分、クロスコンパイルが約120分。

 前者はtimeを前置、後者は記憶の範囲で間違ってないとは思いますが、もしかすると同じくらいだったのかもしれません。

●Raspberry Piカーネルtarballのダウンロードし、ローカルビルド
unzip -q rpi-3.18.y.zip#1307内にもあるURLを参考にraspberrypi/linuxで有効なファイルを指定したhttps://github.com/raspberrypi/linux/archive/rpi-*.*.yのようにしてダウンロード
●git cloneし、USBメモリ用にクロスコンパイル
公式ドキュメント通り、git clone --depth=1 https://github.com/raspberrypi/linux

 結果、Raspberry Pi 400/Raspberry Pi OSにおいてもWaylandベースのGNOMEや追加インストールしたwestonデスクトップ上でWaydroidセッションを開始、起動できるようになりました。

arm64なRaspberry Pi 400/Raspberry Pi OS/GNOME waylandでwaydroid session stop

 GNOME Wayland上の端末から[waydroid session stop]してみると、こんな感じ。

備考

 が、GTK関連の欠落なのか、まだその原因は不明も、ビルドしたカーネルで起動後、WaylandかXorgかに関わらず、メニューは表示されている、バーも掴むこともできなくもないものの、GNOME上のGUIアプリのウィンドウウィジェットの最上段のバーがあるのでしょうが、見えなくなる現象が...。

 また、スクショなどアプリによってはパネル内の操作ができなくなり、苦肉の策でCLIのgnome-screenshotに頼ったため、余計な端末も写っていますが。

 他方、シンプルすぎるほどシンプルな超軽量Waylandベースのwestonでは、また、XベースながらCinammon、LXDEでは全く問題なし。

 あー!わかった...。

 Tweaksのハンバーガーメニューから[デフォルト設定に戻す]とか、[GNOME Shell拡張機能をすべて無効にする]とか、やってみたら、ウィンドウも、ちゃんと普通に表示され、バーも出るし、パネル内の操作もできるようになりました...。

 どうやら、Tweaksアプリというか、[外観]の[アプリケーション]の[テーマ]が[PiXflat]か[TPiXflat]になってて透明化されてたらしいです...。

 なんて余計なことを...透明過ぎてトグルとか、ボタンとかなくなるって...。

 これ以外、何も弊害も障害もなさ気ですが、現時点でRaspberry Pi OSでは、PSIを有効にできない理由があるのか、負荷が高くなることを望まないということなのか、単に需要がなかったということなのか、これら複合的な理由なのか。

 極端に情報が少ないのは、そんなの常識だよって思ってる人以外に需要がないから、あえて説明するまでもないって話なんですかね。

 よくわからないので、これ以上は差し控えます...。

 って世界で唯一と言えるほど詳述してしまった気はしますが。

2023/10/31

 気づけば、apt update時、waydroidについては、次のような認証鍵エラーとなり、waydroidをupgradeできなかったので改めてwaydroid.gpgファイルをダウンロード・上書きして対処(参照先:mmBesar/Tutorials/Waydroid.md)。

https://repo.waydro.id/dists/bullseye/InRelease の取得に失敗しました 公開鍵を利用できないため、以下の署名は検証できませんでした 公開鍵を利用できないため、以下の署名は検証できませんでした: NO_PUBKEY *****

raspberry_pi_400:~$ sudo curl --proto '=https' --tlsv1.2 -Sf \
    https://repo.waydro.id/waydroid.gpg \
    --output /usr/share/keyrings/waydroid.gpg

 既に/usr/share/keyrings/waydroid.gpgも、正しく書かれた/etc/apt/sources.list.d/waydroid.listもあったので、要はwaydroid.gpgを上書きしただけ。

 これで正常にapt update && apt upgradeできるようになりました。

2024/03/31

 これまた気づけば、このRaspberry Pi OS/Raspberry Pi 400でも、先行してWaydroidを入れたDebianでも、いつの間にかWaydroidが起動できなくなっており、何れも原因がわからず、しばらく放置していました。

 Raspberry Pi OSの方は、そもそもwestonは起動できるものの、GNOMEのWayland版デスクトップが起動できなかったため。

 一方、Debianの方は、Wayland版デスクトップは起動していたものの、結果、waydroid upgradeするまで何をしてもダメ、upgrade後、Waydroidも起動するようになったのが昨日のこと。

 というわけでDebianの方で無事、Waydroidを起動できるようになったことから、Raspberry Pi OSの方のWayland、そしてWaydroidも本腰入れてやってみるかと思った次第。

 ただ、Raspberry Pi OSである日突然、起動しなくなったWayland版デスクトップが起動するようになるまでには紆余曲折とSSDなのか、パーティションなのか、ディスプレイなのか、ソフトウェアなのかと振り回される不可解な挙動の数々がありました。

 まず、Waylandについては、約1年前、あらゆるデスクトップ環境を入れてしまう自身の環境においてPIXELしか使えなくなってしまい、その後、Waydroidを入れたくなった際にWaylandがないと話にならずという時、何れもxorg、wayland共に起動できるはずのディスプレイマネージャgdm3だとできず、sddmでいけた後、gdm3に戻してもいけたのでそうしていました。

 Raspberry Pi OSにGNOMEに続き、Xorgのみならず、Wayland(Plasma wayland)も導入していたKDE Plasmaは入れていなかったので、まず、これを入れてみたのですが、Waydroidは起動せず。

 ならばとCinnamon(Xorg)上でPIXEL一択から各種デスクトップを入れた際にも使った[dpkg -P --force-remove-reinstreq]でsddm、task-gnome-desktopや結果、gnome-core、gnome、更にtask-kde-desktopなど依存関係のあるとされたものは、それを先に実行しました。

 そして改めてapt install task-gnome-desktop task-kde-desktop。

 ディスプレイマネージャが複数あると選択を迫られ、sddmを削除した今、wayland未対応のlightdmしかないので、これにも対応のgdm3(あれ?kdm候補になかったけどなくなった?)。

 しかし、再起動してみるとgdm3メニューにはXorg系のみでWayland系がない、westonさえもない状態に...。

 もしや、主流になることが間違いないと目されるも、アルファ、ベータ段階的なwayland、Raspberry Pi OSでは、一時的に外されたのか?と一瞬思いましたが、仮にそうだとしても、あえて使いたい人までは拒絶しないでしょ?ということで継続チャレンジ。

 他方、結果、これらが正解だったのか、後にwayland、その後は、あっさりWaydoridも起動したわけですが、そこにいくまで、ここからが不可思議な挙動に翻弄されることに。

 というのは、何度か行ったラズパイ再起動時、タイミング的にsddmをgdm3に切り替えた後からモニタ(ディスプレイ)が表示されなくなったこと。

 と思いきや、普段ほとんどミュートにしてあるスピーカーの音量を上げ、ラズパイOSにも仕込んである自作スマートスピーカーの準備中や完了時の音声が流れるか確認してみると流れるし、Debianマシンからsshすると接続もできることから起動できなくなっているわけではないことが判明。

 となるとモニタか...、そんな我が家のモニタ(ディスプレイ)は長寿で既に17年経過、それでも見た目も映像も美しく、まだまだ即、買い替えと思うほどでもないものの、ちらつきやHDMIプラグの接触などで不要なところでスリープしてしまうことも割とあり、400固有のキーボードのmicroHDMIポートに負荷がかかるような揺さぶり方もしていたのでmicroHDMIポートの接触不良や破損の可能性も。

 そう思いつつ、電源を落とし、30秒〜1分程度おいてから電源投入を何度か繰り返してみるも変わらず。

 SSDかなと他のマシンにつないでGPartedでシステムパーティションを修復してみるも変わらず。

 電源投入後、起動していることを確認しつつ、ラズパイ400には2つあるmicroUSBポート、いつもと違う方にmicroSD-HDMIアダプタ+HDMIケーブルを挿してみてみると、普段、解像度は1440x900とか1280x720のところが、600x480ではあるものの表示されましたが、[ディスプレイ]パネルを見るとデフォルトモニタではないものとして認識されているようで解像度の変更はできない状態...。

 そこで、もう1度、再起動してみると、今度は、gdm3画面が表示され、ログインしてみた直後、CLIに落ち、レスキューモード?メンテナンスモード?に...。

 メッセージを読むと/bootにマウントすらされなかったとあるも、さっきgdm3画面でたじゃん?と思いつつ、fsck /dev/sda1(ブート・システムのSSDがsda、保存用HDDがsdbだった)してみるもバージョンやファイルサイズなどはあるもcleanなどの文字もなく、プロンプトが返ってくるのみ...。

 CLIのPartedは不慣れなので後で他マシンにつないでGPartedとかで...と思い、仕方なく、exitしてみたら...

 fsckが効いていたのか?gdm3画面が起動、GNOMEとKDEのWayland版デスクトップの選択肢も表示されていたものの、ログインするとブラックアウト...。

 そこで電源断、再投入でgdm3画面が起動、GNOME Wayland版デスクトップも起動でき、KDEのPlasma Wayland版デスクトップもいけるのか?とログアウトしてみるとPlasma Wayland版デスクトップも、更にログアウトしてCinnamon(Xorg)デスクトップも起動することができるようになりました。

 確認のため、改めて従前挿していたmicroHDMIポートに挿して起動するとモニタが真っ暗、何度やっても同じ、その状態でもう1つのポートに挿すと解像度640x480ながらキレイに表示されるということで電源断、これまで使っていなかったmicroHDMIポートに挿して起動すると、あっさり、gdm3画面が表示されました。

 結果、液晶モニタのブラックアウトについては、microHDMIポート(が壊れるような使い方をしてきた自身)に起因していたこと確定。

 幸いあと1つmicroHDMIポートは優しく扱おうと思います。

 肝心なWaylandについては、どこかで依存関係が崩れるようなことがあったのか、wayland版GNOME(デスクトップ環境)の再インストールでなぜかwayland版Plasmaも起動できたことから、gdm3に起因したものだったようです。

 Waydroidについては、Raspberry Pi OSでは、ディスプレイマネージャ+waylandさえ正常なら旧バージョンであっても起動できたことからして、Debianでも同様にすれば...とは言え、waydroid upgradeでそのあたりまで修復された?とは考えにくいので、環境によるということでしょうか...?

 というか副産物もあって先日、AliExpressで買った良さげなHDMIケーブルを挿した後、当該ディスプレイの推奨解像度1440x900が、1368x768になってしまい、どうにも直せず、見づらいので1280xの解像度にしていたのですが、なんと今回、ラッキーなことにこれも併せて直り、1440x900になりました。

ホーム前へ次へ