ConstThe language the app asks for; the routing-map fetch (the network library's own request) carries none.
The build's adaptive-UI flag (MobileApplicationState.adaptiveUi).
The analytics family's own marker. It owns no header of its own: the family
is the analytics hosts' classification, and its headers come from the
facets every request carries (base, zero-rating, app-surface,
api-analytics, network-properties, session-pair, the tasos family)
plus connection-type. The empty facet keeps the family nameable in the
resolver and the header compositions of a request.
The API-analytics header group: the request category tags, the derived
friendly name and the API-stack priority hint. Nearly every request carries
it; the launcher/mobileconfig config-sync surface does not (the app sends
those without the group). Presence is decided by the resolver from the
analytics.apiAnalytics feature, never from the URL.
The app-surface identity. Every API request carries it; the media upload to
the foreign upload host does not, so the media-upload endpoint kind never
selects this facet.
The device fact of a process that began with a stored session: the IANA zone
name, on the process's REST and GraphQL doc requests (450 and 451,
mid-session); a process that began logged out sends none. The
device languages are a REST-only resident of network-session, as the
app sends them.
The network's connection-type headers. They are two facets because the app sends
them apart: every API request carries both, while the music player's download
carries x-fb-connection-type alone (the 451 cold download) — the
player's request set has no x-ig-* header.
x-ig-last-connection-type: the stories-tray request's report of the
connection type. Selected from the request's network.lastConnectionType
feature (the shared tray brick declares it), never from a URL here.
x-msgr-region on the requests the app's Direct stack issues. The value is
the Direct message region the session learned from an
IGRealtimeRegionHintQuery answer (MobileSessionState.msgrRegion; the
448 session learns PRN, the 451 one FRC). The residual regionHint value is the
session's served direct-region hint, which every answer carries empty: the
FX accounts-badge probe sends it, and only a process that began with a
stored session does (x-msgr-region: in the 451 warm launch, absent in
the 448 post-login and 451 launch bursts).
The music player's own request set: the byte range and size-bytes of the chunk,
the player's cache key and buffered-ahead time, and its play origin. All five are
values the download computes (the range and size from the chunk, the cache key from
the URL and the DASH representation, etd_ms from the buffered playback), so the
builder supplies them in HttpRequest.headers and the facet owns their presence and
wire slot. None of them is invented by a provider.
The network's properties spelling of a process that began with a stored
session: its REST requests and its Pigeon uploads (the 451 warm launch's
upload 018). A process that began logged out carries none (the 448
post-login and the 451 launch uploads).
The REST device/network context of a process that began with a stored session: the device languages. The app sends them on the REST requests of such a process (450 and 451, mid-session) and on none of a process that began logged out.
The app's network session (x-fb-session-id / x-fb-session-private): the
REST requests and the media upload of a process that began with a stored
session. The media upload carries the pair (448, a mid-session upload) and none
of the REST-only device facts; a process that began logged out carries
neither, as its API requests and its Pigeon uploads show.
The network stack's three constants of a process that began with a stored
session (the same process fact as the network-session pair): the 448, 450 and
451 apps send them in such a process; the 448 post-login process (a login inside
itself) and the 451 launch process send neither, and the 448
login-recovery process on LTE (also a login inside itself) sends no pair
either. The Android spellings are not the iOS ones (prod_android here,
x-meta-tasos-congestion-config here; iOS sends prod and
x-meta-tasos-congdetect-config), and the values are the same on all three
Android versions. Presence is the resolver's (networkSessionPair), never
inferred here.
The radio half of the tasos family, carried with the trio but only on a
network that reports a radio: the 450 and 451 apps on Wi-Fi and the 448 app on
LTE send both; an emulator's virtual Ethernet NIC sends neither. The value is
the network's own radio spelling (androidTasosRadioMetrics), never a
live measurement.
The app's traffic-telemetry header layer (C01qn's TrafficTelemetryHeadersLayer),
which every first-party request goes through whatever the process state:
it reads the build's MobileConfig string (config 66469 field 2, the signed-in
account's) and adds x-fb-tasos-td-config: <value> while it is non-empty.
This is the line the config-sync request carries alone (launcher/mobileconfig,
no tasos family, one copy of the
string); every request of a tasos-family process carries a second copy from
the native injector (the tasos facet), and the wire joins the two with a
comma. It is the first of the two (registry order is layer order: the Java
layer adds its line, then calls the native injector, C01qn startRequest).
The zero-rating device ids. Presence is the resolver's (it selects this
facet from zeroDeviceIds, the one rule owned by zeroDeviceIdsOf: the
build's zero-rating table and the device's uploaded key); these providers
only render the device's own values.
The zero-rating pair (x-zero-balance / x-zero-eh). Presence is the
resolver's, selected from the presented build's zero-rating table
(zeroRating, the one wire-presence fact zeroDeviceIdsOf also reads);
these providers only render the table's value at the session's phase. A
profile without the table (the 450+ wire) selects no facet and sends
neither header. It rides on every endpoint kind, the Pigeon uploads
included (the 448 app sends it on the z-p42 and graph uploads).
The Android header registry — the single place a header is declared.
A facet is a semantic header group. The resolver (
resolver.ts) decides which facets a request carries fromidentity,endpointKindandfeatures; every header of a selected facet is then rendered by its provider here. A provider returnsundefinedwhen the state it renders from does not exist ("absent by state"); it never decides presence from the request shape — that is the resolver's job.Wire order is not decided here: headers are emitted in
ANDROID_HEADER_SPINEorder and the Rust transport sorts the final wire. Transport-generated headers (transport.ts) are never rendered here; transport-sorted ones (user agent, routing map, zero interface, GraphQL purpose/library) are rendered here and only positioned by the transport.