Choose Android or Windows by the exact CMS/application, hardware, peripherals and IT management requirements. Test the supported OS build, playback performance, restart/offline recovery and update process on the quoted player. Neither OS label guarantees a power level, 24/7 reliability, free CMS services or an upgrade path.
1. Separate the player from the display
An embedded media board, an OPS compute module and an external player are different assemblies. Request the board/SoC, RAM/storage, ports and cooling design for the actual configuration. CPU architecture such as A55 is not the complete SoC model; player-only watts are not the total display input power.
TZD reference platforms differ: IF50 lists Android 14 with octa-core A55/Mali-G52; OD outdoor models list Android 12 with octa-core A55 and 2GB/16GB; DS signage lists Android 11–14 depending on the board. Do not assign one build, chipset or OPS slot to every family. IF50, OD and DS require their own configuration checks.
2. Compare actual configurations
| Check | Android configuration | Windows configuration |
|---|---|---|
| Application/CMS | Verify the supported build, CPU architecture, codecs, HTML5 behaviour and app package. | Verify edition/build, application and peripheral drivers, codecs and output requirements. |
| Licensing | Check CMS/MDM, app and hosted-service terms. Google-service authorisation is a separate question. | Specify the Windows edition, licensing route and CMS/app licences in the quote. |
| Input power | Measure the actual board/player under matched content and output; collect maximum, typical and standby separately. | Use the same test conditions. Hardware, GPU, peripherals and workload determine demand. |
| Recovery | Test power-cut restart, offline content, reconnect and storage-full behaviour. | Test kiosk start, interrupted updates, reconnect and recovery using the deployed policy. |
| Updates | Request security-patch level, owner, support period and a pilot/rollback process. | Confirm servicing channel, update windows, support lifecycle and restore procedure. |
3. Lock the CMS and peripheral requirements
Provide the actual CMS version, content formats, templates, browser features, DRM requirements and network policy. A generic claim that every CMS supports Android or that pilot tiers are free is insufficient. Confirm device/account limits, hosted costs, private-label options, offline caching, logs and support responsibility in writing.
Test USB/serial peripherals, display outputs, touch return and reconnect behaviour with the actual drivers. Type-C naming alone does not establish video or charging. A compatible external input or OPS assembly can enable a compute change, but mechanical/electrical compatibility, licensing and service procedures must be confirmed.
4. Plan security and unattended operation
Record the OS build and patch level, administrator roles, network segmentation and remote-management access. Android security bulletins identify platform fixes; their publication does not prove that an OEM device has received them. Windows edition and servicing-channel choices also require explicit licensing and support checks. Use a representative device group to test updates and recovery before fleet rollout.
Reliability must be tested across the player, panel, power supply, cooling and software. DS20 is listed for 16h/day, seven days/week; other documented DS series differ. Kiosk mode or an OS label cannot extend a display’s approved operating schedule or create a lifetime guarantee.
5. Build a model-specific cost comparison
Include player/board and display hardware, Windows/app/CMS/management licences where applicable, measured energy under the planned schedule, hosting/connectivity, spares and the actual maintenance process. Do not assume Android draws 3–5W, Windows draws 50W, a fixed cost multiplier or that one platform fails first. Comparable samples and written scope are the basis for an RFP.
6. Send a complete player RFQ
- Applications/CMS version, codecs, templates, HTML5/DRM and exact playback tasks.
- Board/SoC, OS build, patch level, RAM/storage, player location and interfaces.
- Source/output resolution, refresh rate, peripheral models and touch requirements.
- Daily schedule, installation/ambient conditions and measured power scope.
- Offline/boot/reconnect tests, logs, management rights, update owner and rollback.
- Licensing, hosted-service scope, support period, spares, warranty and final acceptance plan.
Frequently asked questions
Is Android always cheaper or lower-power than Windows?
No. Compare the actual hardware, licences, CMS/management services, measured power and support scope under matched workloads. An OS-wide wattage or cost ratio cannot replace a model test.
Does kiosk mode guarantee 24/7 operation?
No. Verify software recovery and the approved panel, power and thermal operating schedule separately. For example, the DS20 reference lists 16 hours per day, seven days per week.
Can I switch to Windows using an OPS module?
Only after verifying that the ordered display has a compatible slot, interfaces, power and cooling, and that the module and licences are approved. Do not assume every signage family contains an OPS slot.
Does an Android version prove Google-service authorisation?
No. EDLA/GMS and application availability are separate checks. Request the licensing evidence for the actual model and market before specifying these services.
How should power be compared?
Use matched content, output, brightness where applicable, peripherals and operating mode. Separate player-only consumption from display-system input, and maximum from typical and standby readings.
Sample acceptance checks
- Test the quoted CMS/content with the exact player, peripherals and network policy.
- Preserve approved board, OS build, licence, configuration and update/recovery records.