基礎理解#
私たちは v-a/b パーティションを、スマートフォンを使用しているときに、システムアップグレードを行う際、システムがアップグレード内容を A パーティションに保存し、B パーティションを引き続き使用するものと理解できます。前の V は仮想（virtual）を意味します。使用中の起動状態にできるだけ影響を与えずにアップグレードを行い、rec パーティションでの複雑な操作を省略しました。
詳細理解（私の浅見）#
まず構造について。従来の構造には rec、boot、system パーティションが存在しますが、V-ab 構造では、これらの 3 つのパーティションを廃止し、代わりに boot_a、system_a、boot_b、system_b が使用されます。これが v-ab です。
まず Δ（デルタ、小文字 δ）ファイルについて紹介します。Δ ファイルは cow（copy-on-write）ファイルで、文字通りの意味です。具体的には wikipedia の説明 を参照してください。次に、Google の公式文書を開きます：https://source.android.com/devices/tech/ota/virtual_ab#device-mapper こちらには、super パーティション（スーパー パーティション）について記載されています。
このパーティションは Δ ファイルを保存するために使用されます。したがって、比較的大きなアップグレードを行う際、Δ ファイルが大きくなる可能性があり、事前に分配された super パーティションが不足することがあります。この状況は基本的に Android 11 でのみ発生します。なぜなら、Android 10 は論理パーティションのスペースを 2 倍確保しているからです。Android 10 の VAB パーティション自体はネイティブではなく、動的パーティションを改造したものです。
では、Android 11 のスマートフォンで起動状態のままアップグレードを行うとき、どこでファイルを確認できますか？以下のパスを確認できます：/data/gsi/ota、ここにはいくつかの cow を含む .img ファイルが存在します。どこに存在するかは、システムが割り当てた super パーティションの論理スペースの大きさによります。
次に公式文書を見てみましょう：https://source.android.com/devices/tech/ota/virtual_ab#dm-snapshot-overview こちらには DM 概要が記載されています。その中で：
スナップショットデバイスは、スナップショットターゲットを使用して作成されます。スナップショットデバイスへの書き込みは COW デバイスに書き込まれます。スナップショットデバイスからの読み取りは、基本デバイスからの読み取りか COW デバイスからの読み取りかは、スナップショットがアクセスされたデータを変更したかどうかによります。
これにより、cow ファイルが生成された後、システムが bootContral.hal のマージ状態を snapshoted に変更した理由が説明されます。現在、あなたが a スペースを操作している場合、システムは現在のシステムパーティションを system_a から system_a_cow に変更し、次に B パーティションに切り替えます。この時点で、あなたは引き続きスマートフォンを正常に使用できますが、切り替えの過程で少しカクつく感じがするかもしれません。
cow ファイルが生成された後、システムは再起動を促します。再起動には依然として待機時間が必要で、以前の rec 読み込み cmd インストールとほぼ同じです。この時間、システムは何をしているのでしょうか？
まず、アップグレード前に a パーティションを使用していると仮定します。シャットダウン後、以前の hal ファイルが snapshoted に変更されたため、システムは対応する古いシステムパーティションと Δ ファイルをマージします。しかし、この時点では単にメモリに読み込まれるだけで、バイナリファイルがマージされるわけではありません。この時点で再起動が成功すれば、システムは起動後に残りのバイナリファイルを密かにマージします。この時、システムは bootContral.hal のマージ状態を merging に変更します。もし起動に失敗した場合、システムは古いシステムファイルを直接読み込んでロールバックします（実際にはロールバックではなく、単に読み込むだけです）。起動が成功するまで、hal ファイルのマージ状態は空にされ、次回のアップグレードを待つことになります。
ここまで来ると、あなたはこのロジックが以前の読み込みフラッシュスクリプトによるアップグレードとほぼ同じだと疑問に思うかもしれません。実際、ここでの最大の違いは、パーティションのアップグレードを除いて、最も重要な点は、bootContral.hal の状態が merging のときに、自由にスマートフォンを再起動できることです。そして、bootContral.hal の状態が merging のときだけが、真のシステムアップグレード状態と見なされます。次に、なぜ多くのスマートフォンが以前のスマートフォンのアップグレード効果とほぼ同じに見えるのかを説明します。実際、多くのメーカーはこのマージプロセスにアニメーションを追加することを見積もります…… あなたにスマートフォンがシステムに入っていないように見せかけますが、実際にはスマートフォンはシステムに入っています。ただし、デスクトップが起動していないだけで、このマージ進行状況を表示しているだけです。この時点で再起動すると、再起動後にスマートフォンは残りのファイルをマージし続け、クラッシュの可能性を減らします。たとえクラッシュしても、スマートフォンは古いシステムファイルを直接読み込み、再度アップグレードを行うことができます！
まとめ#
実際、これは私の簡単な理解に過ぎません。また、いくつかのオンライン記事も見ました。Google の v-ab に関する記述はほとんどありません…… 専門家たちの v-ab に関する説明を見た後、私はこの仕組みが実際にはかなりごまかしであることを知りました（途中でシステムパーティション名を置き換える部分……）、また非常に優れたものであり、毎月のアップグレードによるシステムクラッシュの可能性を減少させ、徐々に bl を廃止し始めています……
唯一残念なのは、フラッシュ愛好者にとって、フラッシュの学習コストが再び上昇したことです…