基本的な理解#
v-a/b パーティションは、スマートフォンを使用してシステムをアップグレードする際に、アップグレードコンテンツが A パーティションに保存され、引き続き B パーティションを使用するという意味で理解できます。V は仮想（virtual）を意味します。システムの起動に影響を与えずにアップグレードを行うため、rec パーティションでの複雑な操作がキャンセルされました。
詳細な理解（私見）#
まず、構造について説明します。従来の構造では、rec、boot、systemパーティションが存在しましたが、V-ab 構造ではこれらの 3 つのパーティションは廃止され、boot_a、system_a、boot_b、system_bに置き換えられました。これが v-ab です。
まず、Δ（デルタ、小文字の δ）ファイルについて説明します。Δ ファイルは、copy-on-write（COW）ファイルのことで、文字通りの意味です。詳細については、ウィキペディアの説明を参照してください。そして、まずは Google の公式ドキュメントを開いてみましょう：https://source.android.com/devices/tech/ota/virtual_ab#device-mapper 、そこで次を見てください：このスーパーパーティション（スーパーパーティション）
このパーティションは、Δ ファイルを保存するために使用されます。したがって、いくつかの大規模なアップグレードの場合、Δ ファイルはかなり大きくなる可能性があり、事前に割り当てられたスーパーパーティションの容量が不足している場合があります。その場合、余分なファイルは /data に保存されます。この状況は基本的に Android 11 でのみ発生し、Android 10 では論理パーティションのスペースが 2 倍に予約されています。Android 10 の VAB パーティション自体はネイティブではなく、動的パーティションを改造したものです。
では、Android 11 の携帯電話で電源が入った状態でアップグレードを行う場合、どこでファイルを確認できますか？次のパスを確認できます：/data/gsi/ota、そこにはいくつかの.imgファイルがあり、それぞれにcowが含まれています。それがどこに存在するかは、システムに割り当てられたsuperパーティションの論理空間のサイズによります。
次に公式ドキュメントを見てみましょう：https://source.android.com/devices/tech/ota/virtual_ab#dm-snapshot-overview 、DM の概要の下にあります。次のように説明されています：
スナップショットデバイスは、スナップショットターゲットを使用して作成されます。スナップショットデバイスへの書き込みは、COW デバイスへの書き込みになります。スナップショットデバイスからの読み取りは、基本デバイスからの読み取りなのか、COW デバイスからの読み取りなのかは、アクセスされるデータがスナップショットに変更があったかどうかによります。
これは、COW ファイルが生成された後、システムがbootContral.halのマージ状態をスナップショットに変更する理由を説明しています。現在、a スペースで操作している場合、システムは現在のシステムパーティションをsystem_aからsystem_a_cowに変更し、その後 B パーティションに切り替えます。この時点で、あなたはまだ正常に携帯電話を使用することができますが、切り替えのプロセス中に少し遅延を感じるかもしれません。
COW ファイルが生成された後、システムは再起動を要求します。私たちは、再起動にはまだ待ち時間があることに気付きますが、以前の rec が cmd を読み取ってインストールするのとほぼ同じです。では、この時間にシステムは何をしているのでしょうか？
まず、あなたがアップグレード前に a パーティションを使用していたと仮定します。シャットダウン後、以前の hal ファイルがスナップショットに変更されたため、この時点でシステムは対応する古いシステムパーティションと Δ ファイルをマージします。ただし、この時点ではバイナリファイルのマージではなく、メモリにロードされるだけです。この時点で正常に再起動すると、システムは起動後に残りのバイナリファイルをこっそりとマージし、bootContral.halのマージ状態を merging に変更します。起動に失敗する場合は、システムは直接古いシステムファイルを読み取り、ロールバックします（実際にはロールバックではなく、直接読み取るだけです）。起動に成功するまで、hal ファイルのマージ状態は空になり、次のアップグレードを待ちます。
ここまで見てきたところで、あなたはおそらく尋ねるでしょう、このロジックは実際には以前のフラッシュスクリプトによるアップグレードとほぼ同じではないかと。実際、パーティションのアップグレード以外では、最も重要な違いは次の点です：bootContral.halの状態が merging（マージ中）の場合、いつでも携帯電話を再起動できます。そして、bootContral.halの状態が merging 中である場合にのみ、本当のシステムのアップグレード状態と見なされます。次に、なぜ多くの携帯電話が以前の携帯電話のアップグレード効果とほぼ同じに見えるのかについて説明します。実際、多くのメーカーはこのマージプロセスにアニメーションを追加することを検討しています... あなたには携帯電話がシステムに入っていないように見えますが、実際には携帯電話はシステムに入っており、ただマージの進捗状況を表示しているだけです。この時点で再起動すると、再起動後に携帯電話は残りのファイルを引き続きマージし、クラッシュの可能性を減らします。クラッシュしても、携帯電話は直接古いシステムファイルを読み取り、再度アップグレードを行うことができます！
結論#
これは私の単純な理解にすぎません。また、いくつかの記事を参考にしました。Google の v-ab に関する説明はほとんどないため... v-ab の解説を見た後、これはかなり曖昧なものであり（システムパーティション名の置換中間部分...）、同時にかなり優れていることに気付きました。月に一度のシステムクラッシュの可能性をアップグレードによって減らし始め、bl を段階的に廃止し始めました...
唯一の申し訳ないのは、フラッシュマニアの方々です。フラッシュの学習コストが再び上がりました...