The checkpoint format this library writes. An older released format keeps
decoding, as the root rule of "Only the Latest App Version Exists" says: a
checkpoint written by an earlier release of the library is a version of the
library, not of the app, and its old fields are read into the current layout.
This build writes format 5 and reads format 4 (v4.11.0) beside it; a
checkpoint of an unknown or newer format is refused with
CheckpointDecodeError, never partially restored.
The carried platform parts are part of the format. The set of
ProcessCheckpointRegistries parts — their keys and their encodings — is as
much a checkpoint's format as this number is: adding, removing or renaming a
part changes what a checkpoint holds, so it bumps this constant. A part a
later format added is absent from an older released checkpoint; it is
restored to its declared initial state (ProcessCheckpointPart.initial),
which is the state a process of that build held — the fact did not exist
there — never a guess about a value the older build stored. A part with no
initial makes such a checkpoint undecodable. A checkpoint of the current
format must carry every part, and an unknown part is refused (see
restoreExtras).
Format 2 (released in v4.7.0) added a frame's lookup index (the rows an action
refreshed) beside its visit index, so a restored frame keeps the two apart
exactly as the live one did, and carries the facts a restore continues the
process with: the frame's visit (its id, ordinal, start and shown times), a
swipeable feed's item in front with its own visit, the process's tray
session and the foreground surface trail's navigation source (a screen's
module can depend on how it was reached). A restored departure is then the same visit it was before the
checkpoint — the item in front's included — and the tray keeps its id. It also
adds the interruption: a frame the server brought over the frame below (a
challenge), and the root that is one. The platform parts extended it the same
way (the Android sign-up screens' registration session,
android.registration-session, and the reels viewer's session and visits,
android.reels-viewer-views).
Format 3 drops the telemetry queue from the process part: undelivered
events belong to the process that logged them, which delivers them when it
closes. A format released in a tag is never changed in place: format 5
reads format 4 instead of rewriting it, and a format this build cannot read
(3 and earlier, or an unknown or newer one) is refused.
Format 4 (released in v4.11.0) adds the Android process's running user flows
(android.user-flows, the state x-ig-salt-ids renders) with the readiness
of the QPL logger that renders them: a restored process continues the flows
the checkpointed one was running, and a checkpoint taken inside a launch's
first flight restores a logger that still stamps no header. It also carries the
process's timers as a platform part (Android: android.process-timers, the
routing-map refresh and the Direct presence re-read with when each next fires
and what it repeats, so a restored process fires them when a continued one
would). It also carries the MobileConfig configs the process has read with
the values it fixed for each (mobileConfig, mobile.mobile-config.ts), so a
restored process reads what the checkpointed one read, and the Android
quick-promotion stash (android.quick-promotion-stash, each surface's last
answered batch: the app persists the answer's time across its own restart, so
a restored process does not re-send the batch), and the process's client
address (android.client-address, the public IPv4 the server echoed and when,
which the reels viewer's tail page re-sends). The process's session origin
keeps only whether the stored-session start has begun (begun): the routing
map it once carried is the install's, so it travels in the client state's
device.
Format 5 adds two Android platform parts: the throttling detector
(android.throttling-detector, the process state behind
x-meta-tasos-td-rates / x-meta-tasos-td-signal), so a restored process
reports the detector's form and count the checkpointed one held, and the
comments sheet's once-only reads (android.comments-sheet-reads), so a
restored process skips the restricted-account and shop-eligibility reads the
checkpointed one made. Format 4 shipped in v4.11.0 without these parts and
with the session origin's earlier shape, so format 4 is not changed in
place: it is read. A format-4 checkpoint restores into the format-5 layout
with its missing parts at their initial states — the detector's Waiting and
the reads' nothing held — because a 4.11.0 process had no such state to
save: that is the state it held, not an invented default.
The checkpoint format this library writes. An older released format keeps decoding, as the root rule of "Only the Latest App Version Exists" says: a checkpoint written by an earlier release of the library is a version of the library, not of the app, and its old fields are read into the current layout. This build writes format
5and reads format4(v4.11.0) beside it; a checkpoint of an unknown or newer format is refused withCheckpointDecodeError, never partially restored.The carried platform parts are part of the format. The set of
ProcessCheckpointRegistriesparts — their keys and their encodings — is as much a checkpoint's format as this number is: adding, removing or renaming a part changes what a checkpoint holds, so it bumps this constant. A part a later format added is absent from an older released checkpoint; it is restored to its declared initial state (ProcessCheckpointPart.initial), which is the state a process of that build held — the fact did not exist there — never a guess about a value the older build stored. A part with no initial makes such a checkpoint undecodable. A checkpoint of the current format must carry every part, and an unknown part is refused (see restoreExtras).Format
2(released in v4.7.0) added a frame's lookup index (the rows an action refreshed) beside its visit index, so a restored frame keeps the two apart exactly as the live one did, and carries the facts a restore continues the process with: the frame's visit (its id, ordinal, start and shown times), a swipeable feed's item in front with its own visit, the process's tray session and the foreground surface trail's navigation source (a screen's module can depend on how it was reached). A restored departure is then the same visit it was before the checkpoint — the item in front's included — and the tray keeps its id. It also adds the interruption: a frame the server brought over the frame below (a challenge), and the root that is one. The platform parts extended it the same way (the Android sign-up screens' registration session,android.registration-session, and the reels viewer's session and visits,android.reels-viewer-views).Format
3drops the telemetry queue from the process part: undelivered events belong to the process that logged them, which delivers them when it closes. A format released in a tag is never changed in place: format5reads format4instead of rewriting it, and a format this build cannot read (3and earlier, or an unknown or newer one) is refused.Format
4(released in v4.11.0) adds the Android process's running user flows (android.user-flows, the statex-ig-salt-idsrenders) with the readiness of the QPL logger that renders them: a restored process continues the flows the checkpointed one was running, and a checkpoint taken inside a launch's first flight restores a logger that still stamps no header. It also carries the process's timers as a platform part (Android:android.process-timers, the routing-map refresh and the Direct presence re-read with when each next fires and what it repeats, so a restored process fires them when a continued one would). It also carries the MobileConfig configs the process has read with the values it fixed for each (mobileConfig,mobile.mobile-config.ts), so a restored process reads what the checkpointed one read, and the Android quick-promotion stash (android.quick-promotion-stash, each surface's last answered batch: the app persists the answer's time across its own restart, so a restored process does not re-send the batch), and the process's client address (android.client-address, the public IPv4 the server echoed and when, which the reels viewer's tail page re-sends). The process's session origin keeps only whether the stored-session start has begun (begun): the routing map it once carried is the install's, so it travels in the client state's device.Format
5adds two Android platform parts: the throttling detector (android.throttling-detector, the process state behindx-meta-tasos-td-rates/x-meta-tasos-td-signal), so a restored process reports the detector's form and count the checkpointed one held, and the comments sheet's once-only reads (android.comments-sheet-reads), so a restored process skips the restricted-account and shop-eligibility reads the checkpointed one made. Format4shipped in v4.11.0 without these parts and with the session origin's earlier shape, so format4is not changed in place: it is read. A format-4 checkpoint restores into the format-5 layout with its missing parts at their initial states — the detector'sWaitingand the reads' nothing held — because a 4.11.0 process had no such state to save: that is the state it held, not an invented default.