Google TV or Raspberry Pi for a Signage Device
※本記事にはアフィリエイトリンクを含む場合があります。内容は広告の有無に影響されません。
結論
For signage, Google TV suits putting the same display on many units and a Raspberry Pi suits building one unit out properly — the two take opposite design philosophies.
The hard part is not the display
Showing something full-screen is easy. What is hard is keeping going by itself for months on the premise that nobody touches it.
It must not wander off to another screen, must come back in the morning after going dark at night, and must recover by itself after a power cut. How you build that dedicated-device behaviour is where Android and Raspberry Pi differ completely in character.
With Google TV (Android)
Android has a strong privilege called Device Owner, letting you pin the screen to one app (kiosk mode). You can also turn off only the display at night while keeping the device awake.
Strengths — on a TV-shaped unit, screen, power and audio are one piece; you put it down and you are done. The devices are cheap and it suits lining up many of them.
Weaknesses — heavy model dependence. “One account on the device and you cannot become the owner; start again from a factory reset”, “the unit’s own off-timer cannot be cleared by command and it dies at night” — you sink into per-model swamps.
With a Raspberry Pi (Linux)
Here you lay a rail on an ordinary Linux PC: auto-login → auto-start → browser full-screen in kiosk mode.
Strengths — entirely under your own control. Resident processes, automation and fine configuration beyond display all fit, and quirks like an organisation network’s proxy settings can be handled by hand.
Weaknesses — the initial build is tedious. Auto-login and browser profile generation do not always land first time, and I hit “it booted and no signage appeared” more than once. Wi-Fi was unstable too, and it has settled on wired Ethernet recommended.
Which to choose
Having built both, the split came out like this.
| Condition | What to pick |
|---|---|
| Cheap, just putting up several units | Google TV (hands-off) |
| Building one unit out / needing Linux freedom / doing more than display | Raspberry Pi |
When in doubt, “the same display on many = Google TV / one unit doing various things = Raspberry Pi” will not steer you wrong.
The shared enemy of 24-hour operation is storage
This applies to both, and bites especially on the Raspberry Pi.
Left on continuously, a normal microSD is prone to wearing out from writes. Choosing a high-endurance microSD (the surveillance-camera kind) from the start alone sharply reduces the “sudden death months later, screen black” incident. Unglamorous, but the highest-yield investment.
Where it actually got hard
On the Android side — repeated factory resets from not knowing the prerequisite for Device Owner (no accounts on the device). The off-timer in a model’s firmware could not be cleared by command and had to be switched off by hand from the unit’s own menu.
On the Raspberry Pi side — I ended up having to prepare a recovery procedure for the state where browser profile generation fails and the kiosk does not start. Switched to wired for Wi-Fi instability. The microSD should have been high-endurance.
The nature of the choice
Lined up, the difference is that Android leaves you at the mercy of a model — someone else’s decisions — while a Raspberry Pi leaves you at the mercy of your own build mistakes.
The former adds verification cost as the unit count grows; the latter is heavy for the first unit and then clones from the second onward. Which is lighter is decided by the number of units.
よくある質問
Q1If you had to name one axis for deciding?
Google TV to line up the same display on many units; Raspberry Pi to have one unit do more than display. Choose on those two axes — count and depth of build — and you will not go far wrong.
Q2What should be handled first for 24-hour operation?
Storage. Left on continuously, a normal microSD is prone to wearing out from writes and dying suddenly months later, leaving a black screen. Choosing a high-endurance microSD (the surveillance-camera kind) from the start cuts the incident rate dramatically.
Q3Is Wi-Fi enough on the Raspberry Pi side?
Instability showed in real operation, so we switched to wired Ethernet. On an always-on display, a long time passes with nobody noticing the link went, so certainty takes priority.
この記事の根拠
- ドキュメントファイル
本文の主張は、上の記録に書かれていることだけです。運用しているリポジトリは非公開のため リンクは張れませんが、どのファイルの何行目を、どのコミット時点で見て書いたかは 記事ごとに残しています。推測で書いた箇所はありません。