com.bloks.www.ap.two_step_verification.code_entry — the last-resort
recovery code-entry screen of Android 451, reached when a password login is
answered with the recovery escalation instead of a session (the login info
is no longer connected to an account). It is titled "Check your email",
says "Enter the code we sent to ‹masked contact›", shows the field
"Enter code", the link "Get a new code" and the buttons
"Try another way" and "Continue". It is a pre-session screen: it sets
the client endpoint (inside the CDS container) and is never recorded in the
navigation chain.
It is reached by LoginHomepageScreen.logIn(credentials) when the login
answer carries the ap.two_step_verification.entrypoint_async action; the
login continues with that action and opens this screen. The screen's enter
sends the recorded burst: entrypoint_async (with the login answer's
server_params, the login home still in front) and then the screen fetch
(apps/ap.two_step_verification.code_entry) with the entrypoint answer's
screen params and the flow's aac, once the CDS screen is in front.
Its actions:
submitCode(code) — "Continue": code_entry_async with the code, the
session x-mid as machine_id, the device/family ids, the aac (empty
when the process has none) and the screen's submit action params. An
accepted code answers with the login (the session is applied), and the
action continues the process into its recorded launch — the 451 launch
recording is exactly that post-recovery burst — returning the screen the
launch leaves on top: the feed, or the location-permission splash the 451
recovery launch brings over it. A rejected code raises
AccountRecoveryBloksInvalidCodeError with the server's text ("This code
doesn't work. Check it's correct or try a new one.").
requestNewCode() — "Get a new code": the same endpoint with the screen's
resend action (is_resend_code). An accepted answer is the recorded shape
only — the body's top-level status: ok and the declared empty error slot,
i.e. a new code was sent; any other answer raises
AccountRecoveryBloksUnknownResponseError. An answer that logs the session
in applies it and continues the process into its recorded launch, exactly
as submitCode.
"Try another way" and the help button are not exposed: no recording shows
the request they send. The screen ships without a screenshot: reaching it
needs an account the server escalates to last-resort recovery.
It takes no input: the login answer's escalation is client state
(AccountRecoveryTickets), put there by logIn, which the screen reads on
entry. The escalation edge therefore stores no issuer token in a trail, and a
retrace in a restored process reads the entrypoint from the restored state
instead of failing on an expired one; a process without it refuses with
AccountRecoveryTicketUnknownError.
Evidence: the Android 451 app's login → entrypoint → code-entry flow, its
resend flow and an accepted code.
com.bloks.www.ap.two_step_verification.code_entry— the last-resort recovery code-entry screen of Android 451, reached when a password login is answered with the recovery escalation instead of a session (the login info is no longer connected to an account). It is titled "Check your email", says "Enter the code we sent to ‹masked contact›", shows the field "Enter code", the link "Get a new code" and the buttons "Try another way" and "Continue". It is a pre-session screen: it sets the client endpoint (inside the CDS container) and is never recorded in the navigation chain.It is reached by
LoginHomepageScreen.logIn(credentials)when the login answer carries theap.two_step_verification.entrypoint_asyncaction; the login continues with that action and opens this screen. The screen's enter sends the recorded burst:entrypoint_async(with the login answer'sserver_params, the login home still in front) and then the screen fetch (apps/ap.two_step_verification.code_entry) with the entrypoint answer's screen params and the flow'saac, once the CDS screen is in front.Its actions:
submitCode(code)— "Continue":code_entry_asyncwith the code, the session x-mid asmachine_id, the device/family ids, theaac(empty when the process has none) and the screen's submit action params. An accepted code answers with the login (the session is applied), and the action continues the process into its recorded launch — the 451launchrecording is exactly that post-recovery burst — returning the screen the launch leaves on top: the feed, or the location-permission splash the 451 recovery launch brings over it. A rejected code raisesAccountRecoveryBloksInvalidCodeErrorwith the server's text ("This code doesn't work. Check it's correct or try a new one.").requestNewCode()— "Get a new code": the same endpoint with the screen's resend action (is_resend_code). An accepted answer is the recorded shape only — the body's top-levelstatus: okand the declared empty error slot, i.e. a new code was sent; any other answer raisesAccountRecoveryBloksUnknownResponseError. An answer that logs the session in applies it and continues the process into its recorded launch, exactly assubmitCode."Try another way" and the help button are not exposed: no recording shows the request they send. The screen ships without a screenshot: reaching it needs an account the server escalates to last-resort recovery.
It takes no input: the login answer's escalation is client state (
AccountRecoveryTickets), put there bylogIn, which the screen reads on entry. The escalation edge therefore stores no issuer token in a trail, and a retrace in a restored process reads the entrypoint from the restored state instead of failing on an expired one; a process without it refuses withAccountRecoveryTicketUnknownError.Evidence: the Android 451 app's login → entrypoint → code-entry flow, its resend flow and an accepted code.