maze7

ちょっと進展かも。


persist.service.adb.enable=1で仕込んだイメージをrecoveryに焼く。

そいで、recoveryで立ち上げて、factory reset掛けると/data/recovery/log内容が変わる。
その差分は以下
--

/data/recovery/log

[1] -> factory reset前

[2] -> factory reset後

[1] [UA]FOTA read nv:0x00000050

[2] [UA]FOTA read nv:0x00000010

[1] I:Got arguments from CACHE:recovery/command

[1] Command: "/sbin/recovery" "--wipe_data"

[2] Command: "/sbin/recovery"

[1] init.svc.adbd=stopped

[2] init.svc.adbd=running

--

走ってるねぇ。
じゃあ、factory reset中にadb繋がるんでは？と、試すと。

$ adb shell
error: device not found
★ ここで箱出し泥アニメ
$ adb shell
- exec '/system/bin/sh' failed: No such file or directory (2) -

おおぉおおおおおぉぉぉ。繋がる。

shell用意していないから酢エラー出すのは良いとして、確実にadbdが生きている証拠。

ということは？

factory reset選択後の再起動時には、recoveryパテイメージで立ち上がっているということ。

まー、reset終わるまでの運命ですが。

ちゅか、dataマウントしていますが。

ということは？

やはり、recovery起動時は、recoveryパテイメージとは無縁。したら、bootパテからの立ち上がりしかない。それならば辻褄が合う。あくまでもrecovery起動という判定が入り、そこでsd downloaderを立ち上げる。sd downloaderでfactory reset(もしくはsystem update)選択すると再起動が掛かる。そこからはrecoveryパテからの立ち上がり。

という推測。
んー、ならば、sd downloader起動中にadbdが生きていても良いはずだし、まだモヤモヤするな。

何のために、そんな回りくどいことしているのか謎だけど。

そもそも、bootパテ立ち上げ時に鰤ってもsd downloaderが起動する説明が付かないぞ？

はい、やり直しー

sd downloaderのバイナリ実体て、どのファイルか謎のままだな、そいや。

いあ、にしても、前からそんなもん存在するの？と懐疑的だった/cache/recovery/commandのログが拝めただけでも何か進んだ気がする。"--wipe_data"なの？て感じ。

あと、あれだ、nv_access.koちゅうか、read nvのところ。nvて何だろうな。想像が付いていない。