Android’s own Compatibility Definition Document uses one word for the screen color gamut on a device that does not claim wide-gamut support: undefined. The same compiled DICOM viewer installs on those devices and on calibrated ones alike, across phones and tablets from dozens of manufacturers, running Android versions shipped years apart.
Rendering is not the hard part. The platform handles 12- to 16-bit pixel data, runs a modern GPU pipeline, and already carries production DICOM apps in the field. What decides a diagnostic-grade Android build is what the platform guarantees once that app leaves a reference device, and Android answers that in its own governing documents.
What a DICOM Viewer on Android Starts From
An iPad-based diagnostic workstation starts from a fixed population. One company designs the hardware, builds every unit to the same specification, and controls the operating system update path for the whole line. What changes when the workstation is an iPad is a question about one known device, read against one known set of controls.
An Android build starts from the opposite population. The same compiled app installs across phones and tablets from dozens of manufacturers, running whichever Android version and display panel that manufacturer shipped, sometimes years apart within the same product line. Android’s own compatibility framework describes that population directly rather than leaving it to inference, and the framework is worth reading before any of it gets waved off as generic fragmentation.
The framework does not pretend to close every gap itself. Its own introduction states that where the document “is silent, ambiguous, or incomplete, it is the responsibility of the device implementer to ensure compatibility with existing implementations.” That is Android’s own compatibility document naming the edge of what it guarantees, on the one document whose job is to guarantee compatibility in the first place.
Where Android Leaves the Color Gamut Undefined
Calibration to the DICOM grayscale standard is a hardware requirement no diagnostic viewer gets to skip, on any device. Android’s own rules show how unevenly that requirement lands once the hardware is not one company’s to specify.
Android’s own implementation documentation frames color management as conditional. Devices with wide-color displays running Android 8.1 or higher should support it, but only once the display meets specific hardware criteria, including a well-characterized panel covering the Display-P3 colorspace. Android requires “a factory calibration process that generates calibration data (stored on the device) to adjust for manufacturing variance in display behavior” before that support can be enabled. A manufacturer that skips those criteria does not enable the feature.
The Android Compatibility Definition Document is explicit about what happens on the devices that do not qualify. Section 7.1.4.5 of the Android 16 CDD, last updated December 2, 2025, requires a device claiming wide-gamut support to have a color-calibrated display covering the sRGB gamut.
For every device that does not make that claim, the CDD states the opposite outcome directly. Those devices “SHOULD cover 100% or more of sRGB in CIE 1931 xyY space, although the screen color gamut is undefined.” Undefined is the document’s own word for that whole branch, stated directly rather than a gap the document leaves silent.
API-Level Fragmentation and the Cost of a Long Support Commitment
The operating system underneath that display does not hold still either, and Android does not let a product team pick one version and stop watching it. Google Play’s submission policy requires a moving target, not a one-time check. Its own current requirement states that new apps and app updates “must target Android 16 (API level 36) or higher to be submitted to Google Play” as of August 31, 2026. Existing apps carry a separate clock: they “must target Android 15 (API level 35) or higher to remain available to new users on devices running Android OS higher than your app’s target API level.”
That requirement is dated and tied to a specific Android version rather than fixed for the life of the app, and it applies for as long as the app stays listed. A team scoping a viewer for a five-year deployment is not scoping against one API level. It is scoping an obligation that moves, and that outlives most support contracts written against a single fixed platform version.
Scoped Storage Changes Where a Study File Is Allowed to Live
File access is where API-level fragmentation stops being a calendar problem and starts being a code problem. Android’s storage documentation states plainly that “apps that target Android 10 (API level 29) and higher are given scoped access into external storage, or scoped storage, by default.” That access is limited to an app-specific directory and the media types the app itself created.
That default was not the end of the change. Android 11 (API level 30) closed the workaround that let earlier apps opt out. Once an app updates its target to Android 11, Android’s own release notes are direct about what happens next: “After you update your app to target Android 11, the system ignores the requestLegacyExternalStorage flag.”
A viewer written to pull a study file from wherever a PACS client, a USB transfer, or a referring app happened to place it has to be re-verified against that change. The same code can behave differently depending only on which API level the installed build declares as its target.
Scoped storage has a broader-access escape hatch, and the escape hatch carries its own review. An app can declare the MANAGE_EXTERNAL_STORAGE permission for what Android calls All files access, but Google Play’s own policy “restricts the use of high-risk or sensitive permissions, including special app access called All files access.” The permitted uses Google names for that permission are file managers, backup and restore apps, anti-virus apps, and document management apps, not a category built around diagnostic imaging. Where a viewer’s use genuinely falls within core functionality, Google’s own condition is explicit: “the developer must complete the Permissions Declaration Form and receive approval from Google Play” before the app can ship with it declared.
Writing an Intended-Use Statement Against an Open Hardware Population
Fragmentation does not buy Android a different regulatory bar. The FDA’s own policy on device software functions is explicit on the point: its “policies are independent of the platform on which they might run, are function-specific, and apply across platforms.” Android does not get a lighter compliance bar for being more fragmented, and it does not get a heavier one either.
What changes is who absorbs the variability the platform itself declines to guarantee. Regulatory clearance attaches to a specific device and its intended use, not to a platform-wide claim, whether the reading surface is a fixed monitor, a tablet, or a phone. On a closed hardware population, that specific configuration is one thing to validate and maintain over the product’s life. On an open population, where any manufacturer’s screen might be running the same compiled app, the same intended-use statement has to name the exact hardware and software combinations actually validated.
Otherwise, it stops describing anything a regulator reviewed.
The Questions Android Already Answers for Itself
Read as a spec sheet, Android’s own documentation answers most of what a product team has to decide here, the same way a display manufacturer’s tolerance chart does before a team commits to a panel. That is a reason to read it closely, not a reason to avoid the platform. Four questions come straight out of the documents above, and they are worth putting to any vendor, EBM included:
- Does the target display claim wide-gamut support and the calibration that comes with it, or does it ship with an undefined color gamut?
- What target API level does the app declare today, and what will the next Google Play deadline cost to meet?
- Does the app still lean on a legacy storage flag that a newer release will stop honoring?
- Does the intended-use statement name the specific hardware and software combination that was validated?
EBM mAIn PACS® publishes its own integration surface: native DICOM services covering C-STORE, Query/Retrieve, Modality Worklist, and Storage Commitment. EBM describes that surface as built on open standards, with no proprietary lock-in. Everything that runs above it, on Android or anywhere else, stays the partner’s to build and to scope.
Getting a study onto the device is a separate question from where the file is allowed to sit once it arrives. Query/Retrieve pulls a study from the archive over the network, in operations distinct enough that one of them, C-MOVE, accounts for a recurring class of integration failures on its own. Scoped storage decides what happens to the file after that. And once a study is on screen, the standard does not relax for the platform underneath it: windowing, measurement, and multi-planar reconstruction still have to work the way a diagnostic read requires.
The scoping for all of it starts in Android’s own documents rather than in a vendor’s. The compatibility definition, the storage guide, and the Play policy pages each set a boundary a product team will otherwise meet for the first time at a customer site.