package chromeos_update_engine

Mouse Melon logoGet desktop application:
View/edit binary Protocol Buffers messages

message ApexInfo

update_metadata.proto:319

Definition has been duplicated from $ANDROID_BUILD_TOP/build/tools/releasetools/ota_metadata.proto. Keep in sync.

Used in: ApexMetadata, DeltaArchiveManifest

message ApexMetadata

update_metadata.proto:327

Definition has been duplicated from $ANDROID_BUILD_TOP/build/tools/releasetools/ota_metadata.proto. Keep in sync.

message CowMergeOperation

update_metadata.proto:196

Hints to VAB snapshot to skip writing some blocks if these blocks are identical to the ones on the source image. The src & dst extents for each CowMergeOperation should be contiguous, and they're a subset of an OTA InstallOperation. During merge time, we need to follow the pre-computed sequence to avoid read after write, similar to the inplace update schema.

Used in: PartitionUpdate

enum CowMergeOperation.Type

update_metadata.proto:197

Used in: CowMergeOperation

message DeltaArchiveManifest

update_metadata.proto:330

message DynamicPartitionGroup

update_metadata.proto:275

Used in: DynamicPartitionMetadata

message DynamicPartitionMetadata

update_metadata.proto:289

Metadata related to all dynamic partitions.

Used in: DeltaArchiveManifest

message Extent

update_metadata.proto:101

Data is packed into blocks on disk, always starting from the beginning of the block. If a file's data is too large for one block, it overflows into another block, which may or may not be the following block on the physical partition. An ordered list of extents is another representation of an ordered list of blocks. For example, a file stored in blocks 9, 10, 11, 2, 18, 12 (in that order) would be stored in extents { {9, 3}, {2, 1}, {18, 1}, {12, 1} } (in that order). In general, files are stored sequentially on disk, so it's more efficient to use extents to encode the block lists (this is effectively run-length encoding). A sentinel value (kuint64max) as the start block denotes a sparse-hole in a file whose block-length is specified by num_blocks.

Used in: CowMergeOperation, InstallOperation, PartitionUpdate

message InstallOperation

update_metadata.proto:135

Used in: PartitionUpdate

enum InstallOperation.Type

update_metadata.proto:136

Used in: InstallOperation

message PartitionInfo

update_metadata.proto:131

Used in: PartitionUpdate

message PartitionUpdate

update_metadata.proto:215

Describes the update to apply to a single partition.

Used in: DeltaArchiveManifest

message Signatures

update_metadata.proto:116

Signatures: Updates may be signed by the OS vendor. The client verifies an update's signature by hashing the entire download. The section of the download that contains the signature is at the end of the file, so when signing a file, only the part up to the signature part is signed. Then, the client looks inside the download's Signatures message for a Signature message that it knows how to handle. Generally, a client will only know how to handle one type of signature, but an update may contain many signatures to support many different types of client. Then client selects a Signature message and uses that, along with a known public key, to verify the download. The public key is expected to be part of the client.

message Signatures.Signature

update_metadata.proto:117

Used in: PartitionUpdate, Signatures

message VABCFeatureSet

update_metadata.proto:284

Used in: DynamicPartitionMetadata