XIAOとスマホだけでnode.jsのJohnny-Fiveを動かす最短コースをご案内!

じゃんくはっく
じゃんくはっく

きたきたきたー!

なんか興奮してますね!w

ぴー
ぴー
じゃんくはっく
じゃんくはっく

スマホとXIAOだけでNodeのJohnny-Fiveを動かせるようになったよ!

NodeとかJohnny-Fiveとか何それ?

ぴー
ぴー

はい、ちょっと興奮気味なんですが今日のネタは、

「XIAOとスマホを接続して、それだけでXIAOを制御する!」

ってことがメインテーマです。物理的な接続イメージは図に書くとこんな感じです。node.js実行環境をtermuxに作り、johnny-fiveというnode環境で動作するものをFirmataプロトコルでXIAOとやりとりします。もっと簡単にいえば、

JavaScriptでXIAOを操る ですね。

通常、node.js実行環境はPCに作ったりしますので、物理的な接続イメージは以下のようになるかと思います。

JavaScriptでXIAOのGPIOを操作するのですが、まだこの構成のメリットがよくわかっていませんので、触ってみようと思いました。

物理的に用意するもの

(1) Androidスマホ
(2) Seeed XIAO
(3) ケーブル(Type-C x Type-C)

Androidスマホは手持ちのものでも、余ったものでもOKです。XIAOは3個入りで1800円くらいでアマゾンから購入できます。ケーブルは100円ショップですね。

Androidスマホ の必要アプリ

GoogleStore : Termux

https://play.google.com/store/apps/details?id=com.termux

まず、Androidスマホのアプリを入れておきます。あと、もう一つ有償アプリですが以下を入れておきます。日本円で190円です。

GoogleStore : BT/USB/TCP Bridge Pro

https://play.google.com/store/apps/details?id=masar.bluetoothbridge.pro

これはブリッジアプリで、今回の用途ではXIAOのUSB接続のシリアル通信をTCP上にブリッジする用途で使います。シリアルTCPのブジッジアプリは他にもいろいろありますが、XIAOと接続できた勇逸の神アプリです。

Termuxのセットアップ

アプリを入れたら、パッケージをアップデートしておきます。Termuxのコンソールからタイプするのが面倒なら、PCからSSHして作業するといいかもです。

pkg update
pkg upgrade

以下が今回必要なものです。

pkg install nodejs python clang make openssh -y

手持ちの環境、HUAWEI P20 liteでは以下が入りました。

$ dpkg --list | egrep 'node|python|clang|make|openssh' | cut -b 5-50
clang              11.1.0         aarch64     
make               4.3-1          aarch64     
nodejs             14.15.4-1      aarch64     
openssh            8.4p1-1        aarch64     
python             3.9.2          aarch64     
termux-exec        1:0.8          aarch64 

nodejsはもう14なんですね。速すぎる!ぜんぜんついていけないです。

サンプルソースとインストール

まず、termuxでの操作です。コピペしやすいよう$ は省いておきます。

cd
mkdir j5
cd j5
wget https://github.com/take-i/j5-termux/archive/main.zip

まだ説明も何も書いていませんがそのうち、簡単に書いておきます。

サンプルソース

https://github.com/take-i/j5-termux

サンプルソース解凍しインストール

example にLEDが光るサンプルソースが入っています。

unzip main.zip 
cd j5-termux-main/example/
npm install

IPアドレスを修正

WiFiに接続していると思いますので、termux上でIPを確認しておきます。

ifconfig | grep inet

以下のようなIPv4が出ますので、それをメモしておきます。この場合は、192.168.1.36が自分のスマホのIPですね。

inet 192.168.1.36  netmask 255.255.255.0  broadcast 192.168.1.255

サンプルソースのIPを修正します。portは、あとでブリッジアプリで設定しますので、1024番〜の適当なポートにしておきます。1234でもOKです。

------- example/index.js
::
var options = {
  host: '192.168.1.36',  //host name or IP
  port: 1234  // port
}

XIAOにFirmataをセットアップ

この記事を書いている時はまだ、XIAOはFirmataのコードをビルドするとエラーになりますが、以下を適用すればOKです。そのうち、masterにマージされると思うので、ビルドエラーが出なければOKです。

add seeedunio xiao to boards.h please #475

https://github.com/firmata/arduino/issues/475

具体的には、以下からFirmataをダウンロードします。

firmata/arduino Releases
Arduino-1.0.x-Firmata-2.5.8.zip

https://github.com/firmata/arduino/releases/

先ほどのFixをBoards.hに反映し、ArduinoIDEからインポートします。

スケッチ例>Firmata>StandardFirmata のスケッチをXIAOに書込みます。

エラーなく書き込めたらOKです。

スマホでブリッジアプリを設定

次はスマホで BT/USB/TCP Bridge Pro のアプリを設定します。このアプリはDevceAとBをブリッジしますので画面のように設定します。

XIAOをUSB接続するとアクセス許可がでますのでOKします。「このUSBデバイスをデフォルトにする」はチェックしておいたほうがいいですね。

USBデバイスに接続(USB connect)し、TCP Serverをスタートさせます。2つ上の画像、右側のようになっていればOKです。

起動!

Termuxのindex.jsがある場所で以下のコマンドを実行すると動作します。

node index.js

成功すれば、以下のようにターミナルに表示されているはずです。

Connected to USB2TCP Bridge
IO ready!
1614296838868 Available Firmata  
1614296838874 Connected Firmata  
1614296838882 Repl Initialized  
>> Board connected!

XIAOの青色LEDが光っていれば成功です。写真では青色LEDが光っているタイミングを写せなかったので光っていませんが、チカチカしているはずです。

お疲れ様です。

まとめ

今回、なんとなくわかったのは以下となります。

・Termux上でJ5を使う時は、USBに接続したボードを認識しないので、別アプリでUSBをTCPにブリッジさせて使う
・ブリッジさせるアプリはたくさんあるが、J5からXIAOと通信できたのはこれだけ
・実際に開発するときは、スマホ充電しながらUSB接続しないと電池持ちが。
・J5の使い所がまだよくわかっていないので、例をこなしながらどんなメリットがあるのか体験してみる

あとがき

node.js実行環境をTermuxに作ってそこから有線USB接続したXIAOを操れることがわかりました。まだ、どんなことができるのか、そしてどんなメリットがあるのかまーったく分かっていませんが今後、面白い活用方法などがあれば紹介、DIYしたいなと思います。

著者にメッセージ

間違いのご指摘など、コメントじゃなくて、個人的にやりとりしたい場合はこちらからどうぞ。お返事が遅くなるときもありますが、ご了承を。

    入力内容をご確認ください

    お問い合わせ頂きありがとうございます



      

    2021/01 site24x7 でのSLA状況・統計データ

    じゃんくはっく
    じゃんくはっく

    もう少しだったのにー!

    また落ちたのね?

    ぴー
    ぴー
    じゃんくはっく
    じゃんくはっく

    そうなのよー、1月2日にねー。

    正月だから寝てたのね!

    ぴー
    ぴー

    site24x7のスターターパックを2020の10月から始めています。監視サービスでSLAを99.95%目指していますが、果たしてスマホサーバで達成できるのでしょうか?

    稼働率・SLA99.95%をスマホ自宅サーバで目指せ!まずは1ヶ月間

    LINK

    ちなみに、先月は99.368%で無理でした。かなり惜しかったんですよ!site24x7の監視サービスは強力です。これがなければ、もっとダウンタイムは長かったです。

    2021・01のSLA

    さて、今月の結果から!
    ダウンタイムの合計19 時間 12 分あって、SLAは97.42%となり今月も目標の99.95%には届きませんでした。先月も書きましたが99.95%とは1ヶ月に21.6分以内のダウンタイムに留めないといけません。正月早々に、監視のお知らせはきていたのですが、寝ていて気がつかず! この1日がなければ達成していたんですよー。

    原因は?

    今月も設定ミスではなく、NGINXがBadGatewayを出して本格的に停止していました。

    ちょっと回避が難しいので、運用でカバーしようと思っているんですがやっぱり寝てるときとか無理ですね。

    まとめ

    今回の教訓は以下となります。

    ・UmidigiF2に載せ替えようとおもっている。
    ・4月から仕事先が変わるんで、再起動が難しいかも。何か作戦を練らねば。
    ・バッテリー無くして電源管理と連動する仕組みとか考えないと。

    あとがき

    現在リモート勤務なので、まぁ気がつけばすぐに再起動かけられますがこの先仕事のライフワークが変わる可能性が大なので、再起動がむずかしくなりそうです。バッテリーを外して、電源をリモートからコントロールするとかちょっと工夫しないといけないですね。

    著者にメッセージ

    間違いのご指摘など、コメントじゃなくて、個人的にやりとりしたい場合はこちらからどうぞ。お返事が遅くなるときもありますが、ご了承を。

      入力内容をご確認ください

      お問い合わせ頂きありがとうございます



        

      2020/11と12 site24x7 でのSLA状況・統計データ

      じゃんくはっく
      じゃんくはっく

      だいぶ遅れましたがSLAデータ報告です!

      99.95%は達成できた?

      ぴー
      ぴー
      じゃんくはっく
      じゃんくはっく

      ・・・

      また来月がんばりましょう!

      ぴー
      ぴー

      site24x7のスターターパックを2020の10月から始めています。監視サービスでSLAを99.95%目指していますが、果たしてスマホサーバで達成できるのでしょうか?

      稼働率・SLA99.95%をスマホ自宅サーバで目指せ!まずは1ヶ月間

      LINK

      先月は、99.567%で無理でした。

      2020・11のSLA

      まずは結果から。ダウンタイムの合計17 時間 30 分あって、SLAは97.565%となり今月も目標の99.95%には届きませんでした。先月も書きましたが99.95%とは1ヶ月に21.6分以内のダウンタイムに留めないといけません。

      原因は?

      今月のは設定ミスではなく、NGINXがBadGatewayを出して本格的に停止していました。今の所、root化したtermuxでNGINXを動かすとこの現象が発生しています。

      ちょっと回避が難しいので、運用でカバーしようと思っていましたが夜間にダウンするともう無理ゲーです。

      まとめ

      今回の教訓は以下となります。

      ・サーバが1つだとやっぱりきびしい。多重化が必要だがそこまでコストをかけたくない。
      ・root化したNginxだとBadGatewayが出てしまう。なんとか対策しなくとだが根本原因がまだ不明
      ・運用でカバーしようと思ったが、夜間にダウンするともう無理です。

      あとがき

      目標がクリアできなかったので、記事を更新するのも面倒になっていますが記録だけでも採っていこうかと。ちなみに、12月も無理でしたので、この記事にはりつえておきます。99.368%という結果。

      かなり惜しかったんすが、今回もNGINXがBadGatewayを出してしまいました。17日の少し止まった部分はSSLの更新に伴うWEB再起動ですのでこれはまぁ許容。19日のがなければクリアしていました。NGINXがBadGatewayを出す根本原因を探らないとなのですが、腰が重いです。

      著者にメッセージ

      間違いのご指摘など、コメントじゃなくて、個人的にやりとりしたい場合はこちらからどうぞ。お返事が遅くなるときもありますが、ご了承を。

        入力内容をご確認ください

        お問い合わせ頂きありがとうございます



          

        内部DNSをTermuxのDNSMASQで動かす!

        じゃんくはっく
        じゃんくはっく

        内部ネットワークから参照するDNSを作ったよ!

        それって、どんなDNSなの?

        ぴー
        ぴー
        じゃんくはっく
        じゃんくはっく

        例えば、example.jpだと192.168.1.1にアクセスできるようにするとかできるよ

        UターンNAT対策?

        ぴー
        ぴー

        そうなんですよねー。UターンNAT対策で内部DNSが欲しかったんです。

        内部DNSを低消費電力サーバのスマホtermuxで動かしたいなと思って、いろいろ格闘していました。先日はOpenWrtというルータ上で動かしていましたが、今回は、root化したスマホ上のtermuxで動かしてみました。53ポートで動かすのでroot化が必要ですが、termuxのrootパッケージの1つ、dnsmasqを使って内部DNSを作ろうと思います。

        dnsmasqとは?

        公式:Dnsmasq

        http://www.thekelleys.org.uk/dnsmasq/doc.html

        比較的、軽量でDHCP、BOOTPやPXEにも対応しているDNSサーバでOpenWrtにも使われていたります。自ドメイン以外は指定のDNSに転送して応答してくれます。内部ネットワーク向けの簡易なDNSとしては十分な機能をもっていますね。

        今回は、IPv4で自ドメインの応答とそれ以外は8.8.8.8のDNSにフォワードして応答してもらうだけのシンプル設定です。DHCPなどそれ以外の機能はつかいません。

        Termuxのdnsmasqは?

        ポート53で動かすので、root化したスマホにtermuxを動かしている必要があります。1024番ポート以下はrootじゃないとバインドできません。パッチ内容は以下から参照できます。

        termux-root-packages:dnsmasq

        URL

        やってみましょうか!

        ステップ1 インストール

        インストール自体は簡単です。root-repoパッケージを入れてから、dnsmasqを入れるだけです。

        $ pkg install root-repo -y
        $ pkg install dnsmasq -y

        本体とmanなどが入ります。サイズは264Kと小さいですね。

        $ ll /data/data/com.termux/files/usr/bin/dnsmasq
        -rwx------ 1 u0_a143 u0_a143 264K Aug 17 02:40 /data/data/com.termux/files/usr/bin/dnsmasq*

        ステップ2 設定

        Termuxのdnsmasqだと、設定ファイルはデフォルトで無いので作ります。

        $ cd $PREFIX/etc
        $ vi dnsmasq.conf 

        内容は以下です。ほどよく読み替えてください。

        ホスト設定:$PREFIX/etc/hosts-dnsmasq
        ログ:$PREFIX/var/log/dnsmasq.log
        このホストIP:192.168.1.38
        Termuxユーザ:u0_a143
        ドメイン:gpl.jp
        フォワードするDNS:8.8.8.8

        listen-address=127.0.0.1,192.168.1.38
        port=53
        bind-interfaces
        user=u0_a143
        group=u0_a143
        no-poll
        # プライベートIPアドレスの逆引きを上位DNSサーバに転送しない
        bogus-priv
        # ドメインの無いホスト名のみ問い合わせの場合、上位DNSサーバに転送しない
        domain-needed
        # ローカルエリア内のドメインを指定
        local=/gpl.jp/
        # ホスト名で問合せされた時、下記のdomain=で指定されたドメイン名を補完
        expand-hosts
        # 補完するドメイン名
        domain=gpl.jp
        
        # LocalDNS
        addn-hosts=/data/data/com.termux/files/usr/etc/hosts-dnsmasq
        server=/gpl.jp/192.168.1.38
        server=/1.168.192.in-addr.arpa/192.168.1.38
        log-queries
        log-facility=/data/data/com.termux/files/usr/var/log/dnsmasq.log
        
        server=/localnet/192.168.1.38 # change ip for your ip-server
        server=8.8.8.8
        no-resolv 

        ホスト設定:$PREFIX/etc/hosts-dnsmasq は以下となります。

        192.168.1.38    f2
        192.168.1.47    p3
        192.168.1.47    hack
        192.168.1.47    junkhack

        resolvファイルは自サーバを参照するよう以下にしておきます。

        $ cat resolv.conf 
        #nameserver 8.8.8.8
        nameserver 192.168.1.38

        ステップ3 起動

        53ポートでバインドさせるので、rootで起動します。

        $sudo dnsmasq -C $PREFIX/etc/dnsmasq.conf

        ステップ4 確認

        確認です。明示的に dig @hostip domain と@でdnsを指定するとより良いです。

        $ dig f2 +short
        192.168.1.38
        
        $ dig -x 192.168.1.38 +short
        f2.gpl.jp.
        
        $ dig hack.gpl.jp +short
        192.168.1.47
        
        $ dig yahoo.co.jp +short
        182.22.59.229
        183.79.135.206

        ホスト名のみでも大丈夫ですね。FQDN自ドメインも引けますし、逆引きもできます。管理外はフォワードして応答してきました。

        例えばまったく違うドメインを指定

        $ cat hosts-dnsmasq
        192.168.1.38    f2
        192.168.1.47    p3
        192.168.1.47    hack
        192.168.1.47    junkhack
        192.168.1.111   test.example.jp

        このように、違うドメイン名をFQDNで記載したら参照できるのでしょうか?

        設定変更・再起動

        $ sudo killall dnsmasq
        $ sudo dnsmasq -C $PREFIX/etc/dnsmasq.conf

        参照できるか引いてみます。

        $ dig test.example.jp +short
        192.168.1.111
        
        $ dig -x 192.168.1.111 +short
        test.example.jp.

        参照できますね。これって設定ファイルのserver行でドメイン指定しなくてもいいんですかね? 設定項目はもっとシンプルにできるのかもしれませんが、追求するのはヤメにしておきます。

        まとめ

        同じ設定を、UmidigiF2では動きましたが、Pixel3ではフォワーダーが動かなかったです。

        ・UmidigiF2では動作し、Pixel3ではフォワーダーが動かない原因は不明
        ・機会があれば、BOOTPやPXEも試してみたい
        ・FQDNで記載すれば違うドメイン名でもOK
        ・MXやテキストレコードなどはどうやって指定するのだろう?

        あとがき

        今の所不具合はなさそうです。もう1週間ほど動かして問題なさそうであれば今のWordPressサーバを統合しようかなと思います。メインPCからもこのDNSを参照していますが速度的にも特に問題はない感じです。

        著者にメッセージ

        間違いのご指摘など、コメントじゃなくて、個人的にやりとりしたい場合はこちらからどうぞ。お返事が遅くなるときもありますが、ご了承を。

          入力内容をご確認ください

          お問い合わせ頂きありがとうございます



            

          2020/10 site24x7 でのSLA状況など統計データ

          じゃんくはっく
          じゃんくはっく

          引っ越ししてからのSLAデータ報告です!

          site24x7のレポート?

          ぴー
          ぴー
          じゃんくはっく
          じゃんくはっく

          そうそう。有料会員になったんでとりあえず使っています!

          99.95% って難しそうだね!

          ぴー
          ぴー

          site24x7のスターターパックというのを10月から始めてみました。いわゆる監視サービスなんですが10ドルで契約できるので、ちょっと使い始めています。

          稼働率・SLA99.95%をスマホ自宅サーバで目指せ!まずは1ヶ月間

          LINK

          とりあえず、SLAレポートが出せるのでこれを月末に出していこうかなと思います。

          2020・10のSLA

          まずは結果から。ダウンタイムの合計3 時間 5 分あって、SLAは99.567%となり目標の99.95%には届きませんでした。99.95%とは1ヶ月に21.6分以内のダウンタイムに留めないといけません。しかし、3時間も止めてしましました。

          原因は?

          5日の停止はDNSの設定ミスです。27日と28日は内部ネットワークを少し変更してその影響で少し止まってしまいました。30日は、NGINXがBadGatewayを出して本格的に停止していました。今の所、root化したtermuxでNGINXを動かすとこの現象が発生しています。これはなんとかしないとだめですね。設定関連での停止は、今後以下のように対策しようと思います。

          ・設定変更後、5分は監視レポートが飛んでくるか確認する。

          なかなか設定ミスの間違いには気がつきにくいです。とりあえず何か変更したら、5分は監視サービスの動きを見ることで対応しようと思います。

          まとめ

          今回の教訓は以下となります。

          ・引っ越し当初なんで設定することがたくさんあった
          ・設定変更後は、監視サービスの動きを5分は見て見ることにする
          ・サーバ1つだとやっぱりきびしい。多重化が必要。
          ・root化したNginxだとBadGatewayが出てしまう。なんとか対策しなくとだが根本原因がまだ不明

          あとがき

          UmidigiF2をroot化したので、とりあえずこっちに戻して様子を見ようと思いますが、めんどくさいのでちょっと作業は中断。スマホサーバを安定して動かすのは難しいです。

          著者にメッセージ

          間違いのご指摘など、コメントじゃなくて、個人的にやりとりしたい場合はこちらからどうぞ。お返事が遅くなるときもありますが、ご了承を。

            入力内容をご確認ください

            お問い合わせ頂きありがとうございます



              

            Umidigi F2 をroot化したよ!

            じゃんくはっく
            じゃんくはっく

            Termuxを1024ポート以下でデーモン起動できるから、やっぱりroot化はやっておきたいよね。

            今までサーバ利用していたUmidigiF2をroot化するのね!

            ぴー
            ぴー
            じゃんくはっく
            じゃんくはっく

            そうそう! UmidigiF2の公式ファームウェアを使ってroot化です。

            ちょっと検索してみたけど、まとまってる日本語記事ってないですね!

            ぴー
            ぴー

            さてさて、今日から4連休です! 初日の本日は今までこのブログのWordPressサーバとして約1ヶ月利用していたUmidigiF2をroot化してみましたので、忘れないうちにその方法を書いておきます。日本語でまとまっている情報はなかったので、どこかで役に立つかもしれませんね。

            root化とは?そのメリットは?

            Pixel3・android11(R)正式リリース版でroot化!

            https://junkhack.gpl.jp/2020/10/05/pixel3android11rroot/

            以前、Pixel3のroot化したときも書きましたが、簡単にいえばAndroidの最高管理権限をゲットして普通では出来ないことをやれるようします。なお、同じことをされる場合は、bootを純正以外にしますので自己責任でお願いしますね。

             で、root化する今回の目的も前回と同じで termuxを動かした時rootパッケージを使えるし、1024ポート番号以下のデーモンを起動できます。例えば、WEBサーバの80番ポートや、SSLの443番ポートです。

             というわけで、UmidigiF2のroot化やってみましょうか。

            ステップ1 概要

            こういうのは、まず全体像が見えていることが大事です。UmidigiF2をroot化するにあたり、概要は以下となります。

            ・UmidigiF2のBootローダーのロック解除をする
            ・Magiskというツールを使い、twrpは使わない
            ・Magisk Managerを使い、純正ファクトリーイメージに含まれるBootにパッチする
            ・adb純正ツールで、パッチしたBootをUmidigiF2に書き込む
            ・Termuxはroot権限を利用できるようMagiskに設定しておく

            今回も、Pixel3の時と同じように、Magiskというツールで行いました。TWRPのオフィシャルに行ってきたんですが、てっきりUmidigiF2はTWRP公式ビルドにあると思っていたんですよね。残念ながら、公式ビルドにはないようでした。

            TeamWin – TWRP Devices

            https://twrp.me/Devices/

            一方、MagiskはAndroidパーティションスキームに準拠していれば使えるはずです。オフィシャルサイトであるソース配布元のGitは以下になります。

            Magisk

            https://github.com/topjohnwu/Magisk

            さぁ、やってみましょうか!

            ステップ2 必要なツールと準備

            まずは前準備です。今回もosxでやっていますがLinuxでもWindowsでもChromeBookでもできると思います。オフィシャルのマニュアルも参照してね。

            Magiskオフィシャルインストール手順

            https://github.com/topjohnwu/Magisk/blob/master/docs/install.md

            上記だけでは、全体がまだ見えてきませんね。つまり、ざっくりと以下が必要です。

            (1)fastbootとadbコマンドが動作する環境
             これは、SDK Platform-Toolsを入れればOKです。Googleからリリースされていますので最新を入れておきます。AndroidStudioを入れてある環境ならばすでに入っていますが、ツールだけであれば以下からダウンロードできます。現在の最新は、Version 30.0.4です。

            SDK Platform-Tools 

            https://developer.android.com/studio/releases/platform-tools.html

            (2)UmidigiF2のファクトリーイメージ(StockROM)
             今手元のUmidigiF2で動いているバージョンを確認してください。筆者の場合は最新のUMIDIGI_F2_V1.0_20200402_20200506-1120が入っていたので以下をダウンロードしておきました。これはワイヤレスアップデート画面から現在のバージョンを確認できます。あとから、Boot.imgを取り出してMagiskでパッチします。

            StockROM UMIDIGI F2
             UMIDIGI_F2_V1.0_20200506.V3.17.rar

            https://community.umidigi.com/forum.php?mod=forumdisplay&fid=228

            (3)MagiskManagerのアプリ
             これは以下のオフィシャルサイト(GitHub)からダウンロードできます。筆者はCanaryビルドを使いました。安定番は、MagiskManagerv8.0.2です。

            純正に戻す場合はこれ以外にも必要ですが、今のバージョンをroot化するだけなら以上でOKです。

            ステップ3 ファクトリーイメージを展開

            オフィシャルサイトからダウンロードした、UMIDIGI_F2_V1.0_20200506.V3.17.rar を展開しておきます。rarファイルを展開するといろいろありますが、今回使うのは boot.img と、vbmeta.img です。わかりやすいよう1つ上の階層にでもコピーしておきましょう。

            .
            └── UMIDIGI_F2_V1.0_20200506.V3.17
            ::
                ├── boot.img
            ::
                ├── vbmeta.img
            ::

            ステップ4 Bootローダーのロック解除

            通常であれば、開発者向けオプションの「OEMロック解除」項目はこのようにグレーアウトした状態となっていますが、これをONにしておきます。

            まず、ここにたどり着くには開発者向けオプションを有効にして、次にOEMロック解除をONにします。

            [設定]> [端末情報]> [ビルド番号]を複数回タップして[開発者向けオプション]を有効にしておきます。

            [設定]> [システム]> [詳細設定]で[開発者向けオプション]を開き「OEMロック解除」を有効にし、確認のためにパスワードを入力します。「USBデバッグ」も有効にしておきます。

            次に、USBケーブルでPCと接続し、「adb reboot bootloader」とターミナルからタイプします。

            $ adb reboot bootloader

            すると、スマホはfastbootモードで再起動します。

            再起動したら黒い画面でスマホは止まりますので、以下から認識しているか確認しておきます。

            $ fastboot devices
            F2xxxxxxxxxxxx3	fastboot

            ここから先は、スマホが初期化されますので注意を!

            スマホは黒い画面で左下に少し文字が見える状態だと思います。以下をタイプしてボリュームの+ボタンを押しブートローダーのロックを解除します。

            $ fastboot flashing unlock

            次に以下をタイプしてボリュームの+ボタンを押しセキュアパーティションのロックを解除します。

            $ fastboot flashing unlock_critical

            続けて以下で再起動させます。

            $ fastboot reboot

            起動は5秒くらい遅れますが、ホーム画面がでればOKです。これで先ほどの「OEMロック解除」は以下のようになっているはずです。

            fastbootモード中、スマホの画面に表示される文字が小さくてみずらいですが、上記のように操作すれば問題ないはずです。

            ステップ5 Boot.imgのパッチ

            boot.imgをスマホに転送し、Magisk Managerを使用してパッチを適用します。

            まずは、MagiskManagerのアプリを入れておきます。
             https://github.com/topjohnwu/Magisk

            アプリを入れたら、起動させ「Magiskのインストール」からboot.imgを選択してパッチを当てます。以下のようになれば成功です。

            パッチしたboot.imgファイル(magisk_patched.img)はPCにダウンロードしておきます。

            ステップ6 パッチしたBoot.imgを書込

            引き続き、USB接続したPCから操作です。以下をタイプでリブートします。

            $ adb reboot bootloader

            再起動したら黒い画面でスマホは止まりますので、以下から認識しているか確認しておきます。

            $ fastboot devices
            F2xxxxxxxxxxxx3	fastboot

            カレントディレクトリに、magisk_patched.img があるとしたら以下のコマンドで書込みます。verityしないオプションはつけなくても大丈夫とは思いますが、まだ試していません。

            $ fastboot --disable-verity --disable-verification flash boot ./magisk_patched.img

            以下、実行例です。

                $ fastboot --disable-verity --disable-verification flash boot ./magisk_patched.img 
                Sending 'boot' (32768 KB)                          OKAY [  0.721s]
                Writing 'boot'                                     OKAY [  0.731s]
                Finished. Total time: 1.455s

            オフィシャルのストックロムから取り出した、vbmeta.imgを書込みます。

            $ fastboot --disable-verity --disable-verification flash vbmeta ./vbmeta.img

            実行例は以下です。

                $ fastboot --disable-verity --disable-verification flash vbmeta ./vbmeta.img 
                Rewriting vbmeta struct at offset: 0
                Sending 'vbmeta' (4 KB)                            OKAY [  0.013s]
                Writing 'vbmeta'                                   OKAY [  0.001s]
                Finished. Total time: 0.016s

            最後にリブートです。

            $ fastboot reboot

            root化の確認

            リブート後、MagiskManagerを起動するとこのようになっていると思います。

            例えば、Termuxからrootパッケージを入れて、rootになれるか確認です。

            $ tsu
            # whoami
            root
            # id
            uid=0(root) gid=0(root) groups=0(root)
            # 

            tsuコマンドはtermuxのsuコマンドです。これを行うとmagiskにroot権限を許可するか聞かれますのでOKとしておきます。

            まとめ

            今回、なんとなくわかったのは以下となります。

            ・スマホに入っているバージョンと同じROMをパッチすることでSP Flash Toolを使わなくてもOKだ。
            ・SP Flash Toolは、WindowsとLinuxしかない。
            ・元の状態に戻したい場合は、SP Flash Toolが必要。
            ・今のところ問題なさそう。もう少し遊びながら様子見。

            あとがき

            これでPixel3で試せなかったことが実験できます。本来、Pixel3は、手元であれこれアプリのテストに使いたいので、UmidigiF2がこのブログのメインマシンになる予定です。そのうち、また入れ替えたいと思います。

            著者にメッセージ

            間違いの指摘などコメントじゃなくて、個人的にやりとりしたい場合はこちらからどうぞ。お返事が遅くなるときもありますが、ご了承を。

              入力内容をご確認ください

              お問い合わせ頂きありがとうございます