Start with the moment a license must be issued
There are two different meanings of offline DRM. In the first, each Android device acquires a persistent Widevine license while connected and downloads or receives the encrypted media. During the journey it restores its own local license. The DRM-X Android SDK supports this application model on qualified devices; no on-board license server is required for ordinary restored playback.
In the second, devices cannot obtain licenses before departure. A server on the aircraft, bus, train or ship must issue fresh licenses over the local network, while the public internet is unavailable. A cloud-only endpoint cannot serve those requests. This is an on-board license-service deployment, not a player download setting and not merely a cache of license responses.
A practical on-board licensing architecture
On the ground, your packaging system encrypts the media and associates its Content IDs, key IDs and policies. Encrypted media and approved protected key-provisioning material are transferred to the vehicle. Content encryption keys must not travel as unprotected files beside the movies: use an authenticated, encrypted transfer and deployment-bound key protection with controlled administrative access.
On board, the player authenticates through the local service and sends its device-generated DRM challenge. The licensed server implementation authorizes the request, securely obtains the appropriate content keys and creates a DRM license response for that client. The client CDM—not the on-board application server—decrypts the media for protected playback. Media delivery stays on a separate local origin/cache path.
DRM-X can work with your existing ground encryption and media-loading system. A Linux/container deployment is an option to evaluate against the approved provider runtime and your hardware. Container packaging alone does not establish that the full system can operate without DNS, internet time, online provisioning or external licensing dependencies.
Prove the complete service without a WAN connection
Before promising a fleet rollout, qualify the provider permissions and server SDK, credential activation, device provisioning and renewal, trusted time, certificate lifetimes, revocation behavior and the maximum disconnected period. Confirm how a newly provisioned or replacement seat device is handled when it first appears during a trip.
The acceptance test must physically remove the internet path and cover new license requests, reboot, failover, expiration, content refresh, storage failure and recovery. Successful phone playback with a previously acquired offline license proves the persistent-client model; it does not prove fresh license issuance by an air-gapped server.
- Provider and rights-holder approval for the deployment
- Protected key import, at-rest storage and administrative access
- Local authentication, device limits and signed policy
- Offline time, provisioning and certificate dependencies
- Capacity, failover, updates and auditable recovery
Treat premium content as an end-to-end requirement
Hollywood and other premium catalogs can impose device-security, secure decoding, output-protection, geographic, rental and reporting conditions. Agree those requirements with the rights holder, then map them to the selected DRM, playback hardware and operating procedures. A DRM product name or container image is not a substitute for approval.
When the vehicle reconnects, synchronize the approved operational evidence and content updates without exposing clear keys or credentials in logs. Plan certificate renewal and software updates far enough ahead of the longest disconnected voyage. An operational recovery plan is as important as the first successful playback.
Tell us about your fleet and existing system
Haihaisoft can assess and build a custom on-board DRM service with you. Start by sharing your architecture, required DRM systems, ground packaging/key-transfer process and target player stack. We will identify the integration boundaries, the proof-of-concept acceptance criteria and the deployment work needed before a production commitment.
Include the number of aircraft or vehicles, seats/devices per vehicle, peak simultaneous playback, Android models and firmware, expected resolution, local server CPU/OS, longest disconnected duration and update windows. Also tell us whether the devices are managed seat-back screens, passenger-owned devices, or a mixture: provisioning and entitlement differ substantially.
Common questions
Do we have to acquire licenses before departure?
Not if a properly licensed and qualified on-board service can issue them locally. When that is required, the server deployment and its dependencies become part of the project.
Must we use the DRM-X Android player?
No. Compatible native Media3 players can integrate with the agreed backend/license contract. The SDK simplifies client integration but cannot create an on-board server by itself.
Can you provide a Linux Docker deployment?
A Linux/container deployment can be evaluated for the custom service, subject to the selected provider runtime, permissions, hardware and fully disconnected acceptance. It is not an unconditional claim for every DRM.
Is an on-board service included with the Professional SDK download?
No. Professional and Enterprise provide Android SDK download access. A fleet-specific on-board license service requires separate scoping and commercial agreement.
Platform background: Widevine platform overview. Product behavior and deployment scope are described above; platform capabilities do not imply every customer deployment is qualified.