Lines Matching refs:payloads

44 But everything starts with generating update payloads in (Google) servers for
45 each new system image. Once the update payloads are generated, they are signed
59 payloads, the metadata signatures, the payload size and hash, etc. The updater
212 update payloads from other devices in the network. This has to be enabled
215 of update payloads, all update requests go through update servers in HTTPS.
221 The updater client has the capability to download the payloads using Ethernet,
243 payloads.
254 Once update payloads are generated, their original images cannot be changed
255 anymore otherwise the update payloads may not be able to be applied.
258 different types of update payloads. Its code is located in
266 generate payloads easier, [`cros_generate_update_payloads`] should be used. Most
267 of the higher level policies and tools for generating payloads reside as a
291 data necessary to update the inactive partition. Hence, full payloads can be
296 updating the system using the delta payloads requires the system to read parts
298 reconstruct the target partition). The delta payloads are significantly smaller
299 than the full payloads. The structure of the payload is equal for both types.
308 raw data depending on which produces smaller data. Full payloads are much larger
309 in comparison to delta payloads hence require longer download time if the
310 network bandwidth is limited. On the other hand, full payloads are a bit faster
315 Delta payloads are generated by looking at both the source and target images
317 appropriate partition). The reason we can generate delta payloads is that Chrome
343     operations for better efficiency and potentially smaller payloads.
345 Full payloads can only contain `REPLACE`, `REPLACE_BZ`, and `REPLACE_XZ`
346 operations. Delta payloads can contain any operations.
351 capability of the updater client to accept certain types of update payloads
373 version helps with avoiding to generate payloads that cause that bug to
378 Minor versions are irrelevant in full payloads. Full payloads should always be
381 payloads, we would not have known which version to serve to the client.
385 Update payloads can be signed (with private/public key pairs) for use in
387 help with generating metadata and payload hashes or signing the payloads given
393 payload generation and application. We normally test the update payloads using
520     like the IP address of your Chromebook and where the update payloads are
540 payloads that do not exist on the production update server you can use
549 At each release cycle we should be able to generate full and delta payloads that