Wait for the shell command before sending the next one

[andiwand]

The first full set of store screenshots off CI came back with this status bar, in
all fifteen locales of both devices:

6:54 … and a charging bolt in the battery

Not 9:41, and not the battery dressTheDevice asks for - "plugged false, or
the battery is drawn with a charging bolt in it, which says the picture was taken
on a desk rather than that the app was being used".

What happened

Demo mode did enter: the clock is frozen at the same minute in the first
locale captured and the last, half an hour apart. It is the six commands behind
enter that never landed - the clock, the battery, the notifications, the radios.

shell closed the pipe without reading it:

.executeShellCommand(command)
.use { /* the command runs whether or not anything reads its output */ }

It does not. The pipe is what carries the command's end, so closing it unread
returns immediately and the next command is sent into a device still busy with
the one before. Measured on an emulator, three rounds of sleep 2:

	closed unread	read to the end
round 1	16ms	2004ms
round 2	5ms	2035ms
round 3	12ms	2015ms

On this laptop they arrive anyway, which is why it has always been 9:41 here and
never there.

The fix

Read the descriptor to its end. That waits, and for the demo commands it also
puts them in order: am broadcast answers Broadcast completed: result=0 once
its receiver has run, so there is something to wait for.

broadcast said: Broadcasting: Intent { act=com.android.systemui.demo ... }
                Broadcast completed: result=0

The same helper writes user_rotation, accelerometer_rotation, the night mode
and the navigation bar overlay. None of those were being waited on either, so the
rotation loop and the theme change were racing the same way - the rotation just
had a 2.5s sleep behind it that covered for it.

Checked

The mechanism is measured above rather than argued. Locally the set still comes
out 9:41 with a clean battery, so nothing regressed. The symptom itself only
shows on a slow emulator, so a dry run is going to confirm it on CI - I will note
the result here.

🤖 Generated with Claude Code