アカウント名:
パスワード:
まず、「A/Bシステムアップデート」（シームレスアップデート）はAndroid 7.1で既に導入されている。A/Bというように、アップデート対象のシステムと現在動作しているシステムを分ける方式。例えば、現在システムAが動作しているならシステムBがアップデートされる。更に、アップデートに失敗した際などには先に動作していたシステムから起動できるからより安全でもある。
「ストリーミングアップデート」がAndroid 8.0から導入される機能。これまでのシームレスアップデートではアップデート用のデータをユーザースペースに一旦保存してから、それをシステムに展開していた。「ストリーミングアップデート」では、展開をストリーミングで行い、ユーザースペースに保存する必要がなくなり、容量もほとんど不要になる。
# いくらなんでもシームレスアップデートが7.1で導入されていることが抜けているのはひどいんじゃないかな。ZDNet Japanで日本語にもなってるのに。
まず、「A/Bシステムアップデート」（シームレスアップデート）はAndroid 7.1で既に導入されている。
Androidにその機能が付いているのはそのとおりだが、メーカーが採用しているとは限らない(7.1プレインストールの際に A/B向けの構成にしているかどうかはメーカー次第)のではなかったかな。
Google の Pixel とかはやってるだろうけど。
実際、2017年前半期時点でPixel以外で導入している機種は無いはずですな。
A/Bシステムアップデートを採用している機種は、あらかじめユーザーが利用できないシステム更新用の領域を確保しているのだから、新たにストリーミングアップデートがサポートされたところで何の恩恵も受けないという理解でよろしいか？
旧来のアップデートでもA/Bアップデートでもいったんは/tmpかどこかに展開していたから、/の空き容量がアップデータと同サイズ必要だったんでしょう。それを curl http: ... | tar xvf > /dev/mmcblk0p2 的に直接裏パーティションに書き込むようにしたから、空きが要らなくなったよということじゃないでしょうか。
> A/Bシステムアップデートを採用している機種は、あらかじめユーザーが利用できないシステム更新用の領域を> 確保しているのだから、新たにストリーミングアップデートがサポートされたところで何の恩恵も受けない> という理解でよろしいか？
適当に記事を読んでみた限りだと
A/Bシステムアップデートでは、「システム領域（既存利用側）＋アップデータ適用 ＝ システム領域（今後利用側）」とするための処理におおむね1GB程度のストレージ容量が必要だった
ストリーミングアップデートでは、オンライン側から「システム領域（今後利用側）にブロック単位で書き込めるイメージデータ」を直接取得して書き込みつつ、必要に応じて「システム領域（既存利用側）」のリソースも取り込んでシステム領域（今後利用側）を構築できるので上記「作業用に1GB必要」だったところが、「メタデータを持つために100KB程度必要」まで必要な容量が削減される、という話っぽい
メタデータというのは、既存OSバージョンでの各リソース群と、更新後OSバージョンでの各リソース群における移行が不要で新しいほうを使うべきもの、移行が必要なもの、内容を一部変換しつつ移行が必要なもの、とかの情報なんだろうね
それをいってしまったら8.0プレインストール端末でストリーミングアップデートが対応されるかどうかも疑問。それでもシームレスアップデート対応を新規でやるよりは楽かな?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ見習い
記事がおかしい (スコア: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プレインストール端末でストリーミングアップデートが対応されるかどうかも疑問。それでもシームレスアップデート対応を新規でやるよりは楽かな?