A broadcast intent that should switch the display's input source and does nothing: update the display firmware first, then re-send the command with the action and extras exactly as the intent API document prints them. For content on a schedule, use the player's video-in widget, which switches the input while the player stays in front and the layouts keep changing.
You send the source-switch intent from the CMS, and the display does nothing: no error, no source change, and the player keeps playing as if the command never arrived. Work down three causes in a fixed order. Bring the display firmware current first, then check the command against the intent API document field by field, then decide whether an intent is the right tool at all. For anything on a schedule, the player's video-in widget switches the input while the player stays in front, so the schedule keeps running and there is a way back. This article shows the command format, a worked example with the full command string, and the order of checks that tells the causes apart.
What each symptom points to
- The command sends, and nothing happens at all. Old display firmware, or an action name the display's software does not answer. Firmware is the first suspect: the worked example below is exactly this case, and the update fixed it.
- The CMS reports the send, but the display behaves oddly or throws a formatting error. The extras array is malformed: a missing quote, a stray comma, or the type key left out.
- The source switches, and the player never comes back. The intent opened another source and nothing was set up to return. This is the return-path problem, and the video-in widget avoids it.
- The screen goes black after the switch. The chosen source has no signal on it. That is the input, not the player. If a player shows black on its own video playback, that is a different fault with its own checks: why an Android signage player shows a black screen on video.
- The video-in widget is missing from the player. The player build predates video-in support for signage SoC displays. Check the player's release notes and update the player.
How the command is built
The command is one string with 4 pipe-separated fields:
intent|broadcast|<action>|<extras>
The first field is the command type, intent. The second is the delivery, broadcast, the standard Android mechanism in which one app asks every app that listens to act. The third field is the action string, copied from the display's intent API document. For the source switch on this class of display the document prints cms.intent.action.SwitchSource. The fourth field is a JSON array in square brackets with one object per extra, and each object carries 3 keys, name, type and value; string values sit in double quotes.
The value has to match an input name from the document's list. HDMI1 is the name for the first HDMI input in this document. Other documents number or spell their inputs differently, and the document is the authority. If your CMS gives the command builder as separate boxes for action and extras, fill those; the joined four-field string above is what the builder sends.
After each test send, wait 15 seconds before you judge the result: a broadcast takes a moment to reach the listening app, and a second send on top of a working one can confuse the return path.
Example: switching a 1920 x 1080 display on Android 9 to HDMI1
Inputs. A commercial Android SoC display at 1920 x 1080 running Android 9. The action string cms.intent.action.SwitchSource and the extra, one object with name set to source, type set to string and value set to HDMI1, come from the display maker's intent API document. The 4-field wrapper comes from the CMS command builder.
Rule. Join 4 fields with a pipe character: the command type, the delivery method, the action string from the API document, and a JSON array holding one extra.
Arithmetic.
- Field 1:
intent - Field 2:
broadcast - Field 3:
cms.intent.action.SwitchSource - Field 4:
[{"name":"source","type":"string","value":"HDMI1"}], one object with 3 keys, string type, value HDMI1
4 fields joined by 3 pipe separators make the single command string.
Result.
intent|broadcast|cms.intent.action.SwitchSource|[{"name":"source","type":"string","value":"HDMI1"}]
Decision. Send the string from the CMS to the player paired with the 1920 x 1080 display and wait 15 seconds. On this Android 9 display the command did nothing, because the firmware was behind. After the display firmware was updated, the same 4-field string switched the source to HDMI1 within the same 15 seconds. The threshold: a correctly built command that does nothing points at firmware first; a command whose action or source name is missing from the API document gets rebuilt from the document's names.
Checks, in order
- Open the display's settings and read the Android version and the firmware level, then look on the manufacturer's support pages for newer firmware for the model.
- Rebuild the command from the API document and send the joined four-field string exactly as assembled in the example.
- Wait 15 seconds. If nothing happens, update the display firmware and send it again.
- If it still does nothing, compare the action string and the source value against the document letter by letter, then try a second input name from the document's list.
- If the source switches, stop and read the next section before the command goes into production.
Use the video-in widget when content is scheduled
An intent that opens another source takes the screen away from the player, and nothing switches back: the schedule stops, and the ways home are a second intent aimed at the player or the display's remote control. For an input that has to show during set hours with normal content around it, the player's video-in widget is the simpler answer. On signage SoC displays that support it, the widget switches between 4 inputs, HDMI, DVI, DP and OPS, while the player stays in front, so scheduled layouts keep changing and one layout can hold the external input. The widget needs player support, so check the release notes for video-in support on signage SoC displays before you plan around it.
Two things worth keeping straight. The display's video-in path is its own hardware taking an external signal into the display, which is a different thing from feeding video into a separate signage player; most Android signage players take no video in at all, and the reasons are in why HDMI input rarely works on Android signage players. And the return-path rule is the same one plant floors already apply to panel screens: switch from the controller and switch back on purpose; change HMI screens from the PLC and give control back shows the pattern.
The decision
Recommendation: bring the display firmware current, rebuild the intent from the API document, and test it by hand with a 15 second wait after each send. If the input has to appear on a schedule, use the player's video-in widget and keep intents for occasional manual switches, because the widget keeps the player in front and the schedule intact. Reserve raw broadcast intents for hardware-level changes the widget cannot make.
Per case:
- Intent does nothing: firmware first, then the action and source names against the API document.
- Formatting error in the CMS: fix the JSON, 3 keys per object, strings in quotes.
- Input needed on a schedule: the video-in widget.
- One-off switch by hand: the intent works once a return path exists; send the return intent or keep the remote within reach.
A note on our own range: our panel-mount display range plays its own files from microSD or USB and its HDMI port is an output, so there is no input on it to switch to.
Questions
Can I send a second intent to bring the player back?
Yes, if your CMS can send an intent that opens the player again. Test the return intent by hand before you rely on it, because the return has to work with nobody at the screen. If the return intent is awkward, the video-in widget solves the same problem from inside the player: the input shows in a layout, the schedule decides when, and there is nothing to switch back.
Which source names work in the extra?
The names in the display's intent API document, used exactly as printed there. The worked example in this article used HDMI1 for the first HDMI input. Displays with an option slot list a name for that input too, and some documents spell inputs with spaces or different numbering. An unmatched name behaves like old firmware: the command goes out and nothing changes, so keep the document open while you fill the extras.
Can a panel-mount signage display do this?
No. Our panel-mount Android units play their own files from microSD or USB, and the HDMI port on them is an output only, so there is no input on them to switch to. Source switching belongs to commercial SoC displays that carry their own input hardware and publish an intent API document.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.