Android 8.0ではOTAアップデートに必要なストレージ空き容量が100KBほどで済むようになる 43
ストーリー by hylom
iOSにもぜひ導入を 部門より
iOSにもぜひ導入を 部門より
AndroidスマートフォンやiOSデバイスでは、無線ネットワーク接続経由でアップデートを実行するOTAアップデートを利用する場合、先にアップデートに必要なファイルをすべてダウンロードしておく必要があった。そのためデバイスに空き容量がない場合アップデートが行えなかったが、Android 8では、およぼ100KBの空き容量があればシステムアップデートを実行できるようになるという（ZDNet Japan）。
これは「ストリーミングアップデート」機能と呼ばれており、これによってローカルストレージに空き容量がない場合でもアップデートが可能になるという。また、「A/Bシステムアップデート」（シームレスアップデート）も導入され、アップデートでもデバイスを使い続けられるようになるという。
記事がおかしい (スコア:3, 参考になる)
まず、「A/Bシステムアップデート」（シームレスアップデート）はAndroid 7.1で既に導入されている。A/Bというように、アップデート対象のシステムと現在動作しているシステムを分ける方式。例えば、現在システムAが動作しているならシステムBがアップデートされる。更に、アップデートに失敗した際などには先に動作していたシステムから起動できるからより安全でもある。
「ストリーミングアップデート」がAndroid 8.0から導入される機能。これまでのシームレスアップデートではアップデート用のデータをユーザースペースに一旦保存してから、それをシステムに展開していた。「ストリーミングアップデート」では、展開をストリーミングで行い、ユーザースペースに保存する必要がなくなり、容量もほとんど不要になる。
# いくらなんでもシームレスアップデートが7.1で導入されていることが抜けているのはひどいんじゃないかな。ZDNet Japanで日本語にもなってるのに。
Re:記事がおかしい (スコア:1)
まず、「A/Bシステムアップデート」（シームレスアップデート）はAndroid 7.1で既に導入されている。
Androidにその機能が付いているのはそのとおりだが、
メーカーが採用しているとは限らない
(7.1プレインストールの際に A/B向けの構成にしているかどうかはメーカー次第)
のではなかったかな。
Google の Pixel とかはやってるだろうけど。
Re:記事がおかしい (スコア:1)
実際、2017年前半期時点でPixel以外で導入している機種は無いはずですな。
Re: (スコア:0)
A/Bシステムアップデートを採用している機種は、あらかじめユーザーが利用できないシステム更新用の領域を
確保しているのだから、新たにストリーミングアップデートがサポートされたところで何の恩恵も受けない
という理解でよろしいか？
Re:記事がおかしい (スコア:2)
旧来のアップデートでもA/Bアップデートでもいったんは/tmpかどこかに展開していたから、/の空き容量がアップデータと同サイズ必要だったんでしょう。
それを curl http: ... | tar xvf > /dev/mmcblk0p2 的に直接裏パーティションに書き込むようにしたから、空きが要らなくなったよということじゃないでしょうか。
Re:記事がおかしい (スコア:1)
> A/Bシステムアップデートを採用している機種は、あらかじめユーザーが利用できないシステム更新用の領域を
> 確保しているのだから、新たにストリーミングアップデートがサポートされたところで何の恩恵も受けない
> という理解でよろしいか？
適当に記事を読んでみた限りだと
A/Bシステムアップデートでは、
「システム領域（既存利用側）＋アップデータ適用 ＝ システム領域（今後利用側）」
とするための処理におおむね1GB程度のストレージ容量が必要だった
ストリーミングアップデートでは、
オンライン側から「システム領域（今後利用側）にブロック単位で書き込めるイメージデータ」を直接取得して書き込みつつ、
必要に応じて「システム領域（既存利用側）」のリソースも取り込んで
システム領域（今後利用側）を構築できるので
上記「作業用に1GB必要」だったところが、「メタデータを持つために100KB程度必要」まで必要な容量が削減される、という話っぽい
メタデータというのは、既存OSバージョンでの各リソース群と、更新後OSバージョンでの各リソース群における
移行が不要で新しいほうを使うべきもの、移行が必要なもの、内容を一部変換しつつ移行が必要なもの、
とかの情報なんだろうね
Re: (スコア:0)
それをいってしまったら8.0プレインストール端末でストリーミングアップデートが対応されるかどうかも疑問。それでもシームレスアップデート対応を新規でやるよりは楽かな?
Re: (スコア:0)
A/Bシステムはファイルシステムの刷新が必要なので
旧来からのアップデート対応は不可だったのでは？
んでもって
ストリーミングアップデートが100KBの空き容量で可能なのは
A/BシステムアップデートのA/Bいずれかの領域を使うから
最初っからOS 2つ分ガッツリ使ってるんだから容量馬鹿食いってのが正しい
逆にA/Bシステムアップデートがあるからストリーミングアップデートが可能
よって旧来の端末では
前提となるA/Bシステムアップデートがファイルシステム上対応できないので
ストリーミングアップデートも対応できない
「新規開発端末」でA/Bシステムアップデートやストリーミングアップデートに対応させたAndroid 7.1以降ってことなら可能っちゃ可能だが
# うちのXperia Z5 CompactはAndroid 7.1.1へアップデート済だがその機能は対象外なんだよ；；
Re:記事がおかしい (スコア:2)
正常にアップデートがかかれば必要がない上、ファームウェアで障害を検出できなければ切り替わることのないバックアップにストレージを食われることが
許容できるかどうか、が対応の境目だと思います。
フラッシュが発売時のファームに最低限必要な大きさしかなく、リカバリ用カーネル領域もなく、膨らんだキャリアのバンドルゴミアプリが入れられなくなる
という理由で海外版のみアップデートが配信されたXperia Arcを思い出しますね。遥か過去の端末ですが、ソニエリ系はその頃からストレージの無駄遣いには
敏感だったものです。
いくらアップデートしやすくなっても (スコア:2)
アップデートが実施されるかどうかはメーカーしだいだしなあ > 特に日本語版。
Re:いくらアップデートしやすくなっても (スコア:1)
きちんとアップデートされ続けているのって、世界中で数が出ている一部のモデルだけでしょ。
SamsungやXiaomiとかでも、ハイエンド寄りのモデル以外は意外に放置になっていますよ。
まあ、どっちかというとユーザリソース(インストールしたアプリやデータ等)でストレージ容量を逼迫される場合の対策ではないかと思いますが。
# シーケンシャルなFOTAとか、評価試験が面倒すぎて対応しないメーカーも多そうな気が。
失敗しそう (スコア:0)
途中で接続切れたらどうなるの？
嫌な予感しかしないんだけど・・・
Re: (スコア:0)
それで嫌な予感て想像力なさ過ぎでしょ
Re: (スコア:0)
あり過ぎならわかるけど、なさ過ぎ？
あなたのご想像をぜひ
Re:失敗しそう (スコア:1)
「あなた」ではないけどさ。
PCで言うところのBiosが2個あるよーなもんなんだから
「接続が切れようがなにしようが、B領域のアップデートが終わるまで現行のA領域を使い続ける」
以外にどんな想像が出来るの?
Re: (スコア:0)
Aをアップデートしようとして失敗しBに切り替わる。
次にBをアップデートしようとして失敗しAに切り替わって合掌。
#最近、強制アップデート→ブルースクリーン→回復→強制アップデートを
#数カ月周期で繰り返しているうちの子はそのうち起動不能になるだろう。
Re: (スコア:0)
アップデートが完了するまで切り替わらないと思いますが。
Re: (スコア:0)
それってどんなアップデート方法でもケチつけれますよね？
何か意味あるんですか？
Re: (スコア:0)
救いが無いほど頭の悪いエンジニアですら、そんな設計しないよね。
存在する可能性のあるケースでの不安はないの？
Re: (スコア:0)
そうすか？
折角の冗長系なのに、A/B同時に最新版にしたがるんですよ、ウチのえらい人。
なぜかって、そりゃA/B同時に運用しているからです。(冗長ってそういう意味じゃないよね。>えらい人)
Re: (スコア:0)
ウチがそうだからってandroidもそうだって？
と釣られてみる
Re:失敗しそう (スコア:2)
同時に最新版が二本あるって、ディスク障害対策ですよね。A/Bアップデートは未導入ということですよね!
ホット系のディスクAとBに加えコールド系のディスクC/Dを用意してA/Bアップデートをはじめましょう!
Re: (スコア:0)
全滅に備えてE/Fも用意しようぜ！
Re:失敗しそう (スコア:2)
ここに全く違う高単価の外注先に出した、単機で全系復旧までをしのぐ軽量高信頼の予備系がですね……
# 安易な航空宇宙ネタ
Re: (スコア:0)
Re: (スコア:0)
すげぇｗマジモンのアホがいたｗｗｗ
Re: (スコア:0)
> PCで言うところのBiosが2個あるよーなもんなんだから
全然違いますよ
BIOSが2個あるような仕組みだと
ストレージが2個分、つまり倍必要になります
そのような方法はローカルストレージに空き容量がない場合だと利用できません
空き容量が100KB程度ですむ，ということは
おそらくは BIOSの相当するコアの部分を100KB程度のモジュールに細かく分割して
その分割したモジュール単位でAとBの領域に分けて順番に更新するんでしょう
しかしこの機能は Android 8.0までは実現されなかった機能です
少なくとも技術的に高度な事をしていますし
それに伴うバグなり想定外の不具合は起きても仕方ないと思います
Re: (スコア:0)
シームレスアップデートは、ストレージを倍使って、稼動していない側を安全にアップデートしたうえで切り替えるもの。
切り替え時には再起動する必要があるが、通常通り使っている間にアップデートは完了しているので、再起動が通常の再起動と同じ程度の短時間で完了する。
100KBの空きでアップデートできるストリーミングアップデートは、通常のアプリのアップグレードと同じような単位で、システム側もアップグレードできるようにする方式。こっちは切り替えとかもしないし、再起動もしない。運用中に小さいアップデートを行なうためのもの。
2、3世代前の Samsungで採用になって、ずっと運用されて十分に実績のあるセキュリティアップデートが標準 Androidでも使えるようになる話だよ。
根本的に別物。
Re: (スコア:0)
マイナーアプデはできても大規模なのは難しそうだけどそんなのができるのか
Re: (スコア:0)
システム領域A（起動中）：1GB
システム領域B（更新中）：1GB
ダウンロード イメージ： 500MB
が
システム領域A（起動中）：1GB
システム領域B（更新中）：1GB
ダウンロード イメージ： 100KB
になるんだろ。
Re: (スコア:0)
なぜ失敗するロジックにしようとするのか理解に苦しむ
Re: (スコア:0)
そこで100KBの出番ですよ 詳細知らんけど
Re: (スコア:0)
100ケルビン・バイトは何ジュール？ 詳細知らんので
Re:失敗しそう (スコア:1)
バイト(情報量)は無次元量なので、ケルビンバイトの次元はケルビン。基本単位なのでジュールには変換できません。というマジレスはさておき、
SI接頭辞の小文字のk=kilo=1000と区別するために、Kibi=1024を大文字のKで記述する(102400Bytesを100KBと書く)のは一般的 [wikipedia.org]ですよ。
mBに対してミリバイトって何?ってツッコミはまだ理解できますが、
KBにケルビンバイトって何?ツッコミを入れるのはダメでしょう。
情報量と熱量 (スコア:0)
ランダウアの原理 [wikipedia.org]からみると
100キロ・バイトで10の-13乗ジュール未満てとこ [sustainablejapan.net]ですかね。
"変換"ではなくて、100KBのデータを消去するのに発生してしまう熱量ですけどね。
普通は、読み書きの"手段に必要なエネルギー"のほうが桁違いに大きいはずなので、一般人が観測できることはないでしょうけど。
Re: (スコア:0)
え・・・kiBって書くもんだとおもってたけど。
Re: (スコア:0)
キビバイトはKiBですね。iが抜けてたら駄目です。
空き容量は100kBあればいいけど (スコア:0)
システム用に別途予約した領域が用意されていて、そこをつかってアプデする仕組み
実際には数GB無駄？な領域があるという・・・
Re: (スコア:0)
システムの専有領域を二倍取って置いて、空き容量がわずかでもOKとか、100円配当してやるから10000円投資しろって話と変わらんのじゃないかと。
Re: (スコア:0)
上場株式の配当は平均1～2%/年ですよ。
それは普通の水準です。
0.001%つけてやるから、預金しろよりずっと誠実です。
え、違くない？ (スコア:0)
空き容量が少なくてもじゃなくて、システムパーティションを2つ持つ話なんでしょ？
最初から予約されてるだけじゃないですかー
これ、実際に使われるのはスマホではなく組み込み系でしょ (スコア:0)
ストレージ容量にそこそこ余裕があり、かつ
移動中の自身やモバイルWIFIルータの3G/LTE通信の断絶を当然考慮しなきゃいけないスマホでは
今回のようなアップデートは（Nexus/Pixelとかでは当然試験実装するにしても）そんなに使われないでしょう
そしてそれが正しい
それに対して、最初から容量を切り詰めており
さらに一般的には特定の店舗有線LANやWIFIに接続していて通信の安定性のほうは十分に高い組み込み系デバイスでは
今回のようなアップデートは有益でしょう
実際には、店舗（とか）が閉店後や、配布されたAndroid組み込み端末をいったん部署ごとにとりまとめ回収したあと
多数のAndroi組み込みd端末を作業員が夜中にまとめてアップデートしておくという運用になるんでしょうけど