ReadonlybackgroundThe app went to the background: bc, and whatever else the platform keeps per moment (the shared part as for foreground).
ReadonlyforegroundThe app came to the foreground: fc and a new private id, and whatever else the platform keeps per
moment. Only the platform's own part: the part every platform shares — a moment ends what the Pigeon
server named in the process, so the next upload asks for the identity again — is the core's
(AppEntersForeground, EndNamedPigeonIdentities), and a caller that runs a moment runs it
through them.
ReadonlyforegroundHow many times the app came to the foreground in this process, read now.
The Pigeon upload session id counts from it (pigeonSessionId): the
first foreground opens the session -0, every later one is the next
number.
The app's own lifecycle moments, as the platform that renders them models them: the app went to the background, and the app came back to the foreground.
The moments are the app's, not a screen's, and several things happen at each one: the Android network session counts
bcon the background andfcand a new private id on the foreground, the user flows started as cancellable on background end (EndBackgroundCancellableUserFlows), and a screen'sresumeruns when the app comes back. The screen part and the user flows are the core's own; the network session is the platform's, so a platform installs this service with its two effects, and the one place that knows a moment happened — the return from the background (restoreAsAppReturningFromBackgroundOf,screens.checkpoint.ts) — calls it there, after the checkpoint's process state is put back and before the resumed screen's own requests, so a restore that refuses or rolls back never counts a moment that did not happen.A platform that models no app moments (iOS) provides none, and the core's return from the background runs the rest of its work unchanged.