The selected adapter or app segment is solid purple with a soft glow instead
of grey, the selected connection option gets a purple-tinted row and a filled
icon tile, the current step and the primary button glow, and a faint purple
wash sits behind the step track.
Choosing a USB cable or a tablet app switches the connection at once, which
counts as setup done, so the card closed under the person's finger and left
no way to change the choice. A choice made in the card now holds it open
until Done. In the guided setup the home card's button reads Change how your
car connects, so the way back is visible.
Done steps and checks use the theme's success color, the current step and
selection use the primary purple, text uses Galaxy's Inter and weight tokens,
and the connection options use the outline icons the rest of the page uses
(car-front, usb-symbol, usb-c, tablet) on a single primary-tinted tile
instead of Apple's multicolour gradients.
The guided card's lists, paired-car rows, checklist rows and handshake
disclosure now use the page's own gx-starport-list, gx-starport-row,
gx-starport-row__text and gx-starport-wiki classes, restyled once for the
card, instead of parallel guided-only copies. Radii, spacing and motion use
Galaxy's tokens. Only the step track, icon tiles, radio rows, segmented
control and checklist marks remain new, and the block is about a fifth
shorter.
The guided card is rebuilt in an Apple-style: a three-step track (support,
car, connect) that fills as setup moves along, a large title, inset grouped
lists with coloured icon tiles for how the car connects, a segmented control
for the adapter model and the tablet app, iOS-style checklist rows for the
connection, and one full-width primary button. It uses Galaxy's theme colors
so light and dark both work, and reads cleanly down to a phone.
The classic step 2 and the home card's dropdowns now render only in the
classic setup. The guided card replaces them and hosts the page's own
pairing, cable and app instructions and the Connect button, so nothing is
lost. A finished setup can be reopened from Setup and Pairing, and Done
closes it. Paired cars the page's own list does not show yet are offered in
the card; the rest stay in the pairing step.
The logs bundle, and so the Discord send, now carries report.json: the same
tags and per-session detail a Bugsink report has (setup, offered modes, reach
class, ladder, SDP, strategy) for the newest five sessions, sanitized and
size-capped. It is built best-effort: if it cannot be, the bundle is
unaffected.
The adapter setup's 'Connect your paired car in Galaxy Bluetooth first'
refusal (27 Bugsink reports) now shows a step with a link to Bluetooth, next
to the usual question while setup is unfinished and alone once it is done.
The comma can stay powered between drives, so the three passes belong to an
ignition (an onroad start), not to a boot; a reboot still resets them. When a
learned strategy is dropped after two handshake failures the ladder carries
on from the next rung instead of starting at the one that just failed, which
the dongle flip also avoided.
Choosing the only paired Android Auto car from housekeeping runs with nobody
at the screen, and selecting a receiver unselects that device as the
Bluetooth audio output. It now skips a car that is the selected audio device,
or when that cannot be read, leaves it to the setup screen's Use button. It
reports problems once instead of every 20 s and gives the projection role
back, keeping only the standby gateway auto-connect needs.
The 686 pre-video failures Bugsink showed (54 distinct texts) are kept as a
fixture. The test checks the intended class for each: Host is down and page
timeouts are a sleeping car, refused and unanswered handshakes are not ready,
and anything after the link is up is not a reachability problem. Reports tag
the reply style and Wi-Fi band the working strategy used.
Reports carry the SDP outcome (where the RFCOMM channel came from and how
many retries it took). The Discord post names the handshake options tried
and how each ended. A car that once needed 70 s to be ready now gets that
many stage timeouts to answer the Wi-Fi handshake, never fewer than the
standard wait and capped at nine.
A card above the classic steps asks one question (how does the car connect:
built-in wireless, adapter, USB cable or app), shows only the instructions
for that answer, and lists paired cars that offer Android Auto to choose
between when there is more than one. While connecting it shows a live
checklist of the stages (Bluetooth, the car's Wi-Fi, securing the connection,
the dashboard), a list of the handshake options being tried once one has
failed or one is remembered, and a notice that the first connection can take
a few minutes or more than one drive. Every action is one the page already had.
The card is on by default; Use classic setup turns the switch off, and Try
the guided setup turns it back on. Returning drivers see the card only while
a connection is in progress. The state function is pure and tested without a
browser.
The setup response carries newSetup, and a new_setup control action turns the
guided setup off or on. It is handled before the StarPort-enabled check and
never calls the daemon, so it works as the way back to the classic screens
when the service is off or broken. It needs a signed-in session and park.
One module now decides how to answer a car's handshake, and it is also the
learned profile: the strategy that last worked is the one tried first.
The first pass is today's behavior. Later rungs are knobs that already
existed: the other version reply (the flip the dongle work added, now owned
here), the phone-style reply with both bands and with 2.4 GHz only, a longer
wait for a car that keeps saying not ready, and, for adapters only, the
handshake variations.
A failure advances the ladder only when the car answered the version
exchange, then went silent or refused the Wi-Fi setup, before any video was
acknowledged in the session. A sleeping car, this comma's own Bluetooth
trouble and anything after video (a car shutting off) never move it. Three
passes per boot at most, resuming at the first untried rung on the next
ignition; a learned strategy is dropped after two handshake failures; a
session that streams for a minute makes its strategy the learned one.
State is a small per-car file beside the config (setup_state.json, newest 16
cars, damaged or unreadable means a fresh start, never blocks a connection).
The status exposes the ladder for the setup screen, and reports carry what
was tried, how each rung ended and how long the car took to be ready.
Allow H.265 video (Developer > StarPort, off by default) lets a car that
offers only H.265 get H.265. A car with an H.264 mode is chosen exactly as
before whatever the setting; this is replay-tested over several offers.
The hardware encoder library is ABI 4: an HEVC option selects H.265 Main
profile at high-tier level 5 and allows up to 1920x1080 (H.264 stays at
1280x720). The Python side keeps H.265 apart from the H.264 code: its own
codec-config and wire-frame functions for the two-byte NAL header, its own
access unit check, and an encoder subclass. If the car is told H.265 and the
hardware encoder cannot open, the session fails with the reason; there is no
fallback to another codec.
Measured on a parked comma with a scratch copy of the library: H.265 1080p
costs about 13 ms per frame on the NV12 path (30 ms from RGBA), mid-stream
keyframes carry VPS/SPS/PPS, and the H.264 session is unchanged. The
encoder splits every H.265 picture into two slices, which the check allows.
A car that is paired and offers wireless Android Auto but was never chosen
(the pairing window closed first, or it was paired in Bluetooth settings)
is adopted by housekeeping when it is the only candidate. This reads the
cached BlueZ service list, so it never pages a device, and it does not run
during a pairing window or session, for adapter setups, or once a car is
chosen. With several candidates nothing is guessed; they are listed in the
status as car_candidates for the setup screen to offer.
The first version waited on any state below disconnected, which also caught
the unknown state and broke the lease tests. Wait on states 10 and 20 only.
Nineteen Bugsink joins were refused with 'device is strictly unmanaged'.
On a shared interface the join now waits up to 8 s for NetworkManager to
manage it (dedicated mode already waited) and otherwise reports that the
interface is unmanaged and for how long, which the diagnosis already maps
to wifi_not_ready.
Stream losses keep the projection_interrupted category but now carry a kind
(stalled, silent, disconnected) with matching next steps, reported as
aa.loss_kind, so a car shutting off is no longer read as link loss.
The Developer page gets a heading row, StarPort, that groups the StarPort
settings: the New pairing experience switch (on unless turned off), Stay on
Wi-Fi (moved under the heading, same key, label and default) and Allow
H.265 video (off by default, daemon setting allow_hevc).
The heading is a row whose key starts with heading:, projected with
heading=true. It has no choices, is never available and cannot be changed,
and Galaxy draws it as a label. The new pairing switch is a plain file next
to the other StarPort data rather than a Params key, so it reads and changes
with the StarPort service down and needs no device rebuild; absent or
unreadable means on.
Most failed drives in Bugsink never reached video and stopped at Bluetooth,
but one backoff treated a sleeping radio, a service that was not up yet and
this comma's own busy stack alike.
reachability.classify() separates a car that never answered a page (Host is
down, page timeout), a car that answered but refused or reset, and a local
Bluetooth failure. A sleeping car or busy controller now waits at least as
long as before and often longer; other failures wait exactly as before. A
sleeping car no longer makes the comma forget the cached RFCOMM channel.
The class is logged on attempt_failed and reported as aa.reach_class.
The 141 'unknown' failures at the discovering stage now get a diagnosis:
car_asleep, car_not_ready or bluetooth_stack_busy, with next steps.
The Discord post now names the setup type, profile and whether it was
chosen or detected, from the newest session log that recorded one, next to
the car and head unit. The zip already carries the same data in each
session log's session_start and discovery events.
Reports could not tell a built-in unit from a dongle, and offers and
handshakes were only visible in failure text, so there was nothing to
compare working pairings against.
session_start now records the setup type (builtin/adapter/usb/app), the
resolved profile and whether it was chosen or detected. Session reports
carry every video mode the head unit offered, whether the comma's address
reached the car in the pairing request, and, for streaming sessions, the
strategy that worked (window, reply style, Wi-Fi channel type). The drive
report gains low-cardinality tags (aa.setup_type, aa.adapter_model,
aa.profile_source, aa.phone_address_sent); long values stay in contexts.
Old logs without these fields still report. aa.schema is now 3.
LeaseAwarePhone (used for every wireless session) had no adapter() method,
so Supervisor._adapter_address() hit AttributeError, swallowed it, and
returned "". The Bluetooth-service pairing request was therefore never sent
(bluetooth_opened always logged phone_address: "").
A 2020 myChevrolet (head unit 2.46.1.6) through an AAWireless Two+ then
accepted and acknowledged video but never showed it. A real phone sends the
pairing request about 1 s into the session; the car shows Android Auto once
its hands-free link to that address is up.
Pass adapter() through to the wrapped BluezPhone. It is a read-only property
lookup, so it needs no phone-role lease, like devices() and device().
_adapter_address() now logs adapter_address_unavailable instead of failing
silently.
Tested on the car (session-000052): phone_address sent, pairing response
received, picture displayed, touch input worked, 20-29 fps fully acked.
Co-authored-by: droobah <34214975+droobah@users.noreply.github.com>
Adds a Send logs card to the StarPort Logs page so a user can report a
problem with all of their reportable logs: an optional note of up to 60
characters, and the same zip as Download all logs, sent from the device to
the developer's log inbox. Each device keeps its own thread, titled with the
car fingerprint and a hashed device tag. Manual sends only; no automatic
failure reports. If the zip is over the 10 MB size limit, it is resent
without the device snapshot.
dirwin31