Known Limitations Library for Android Device Rollouts
A structured library for recording OEM, Android, MDM, app, certification, logistics and lifecycle limitations before a device rollout scales.
- By
- Vantora
- Published
- Updated
Limitations are part of the evidence, not a failure
Known limitations help a rollout proceed honestly. They record what is accepted, what is conditional, what needs a workaround and what should block production until resolved.
Known limitations categories
| Category | Example limitation | How it is handled |
|---|---|---|
| OEM or model | Boot animation, firmware option or accessory fit is model-dependent | Record selected model, dependency owner and fallback path. |
| Android or GMS path | AOSP/GMS decision changes app distribution or service behavior | Link to build spec and app acceptance checks. |
| MDM and policy | A restriction depends on device-owner mode or MDM support | Record policy group, tested behavior and unsupported controls. |
| App and backend | Offline queue, login or update behavior depends on customer app | Assign to app owner and keep open until sample test passes. |
| Market, carrier or certification | Target-country certificate, carrier acceptance or importer role is unresolved | Flag as target-market dependency before production commitment. |
Download the library template
FAQ
Should limitations be shown to the buyer?
Yes. A visible limitation record makes sample acceptance stronger because it separates accepted behavior from conditional or unsupported behavior.
Can a limitation be accepted?
Yes. A limitation can be accepted if the project owner agrees to the condition, workaround or exclusion and it is recorded in the build spec.
What limitations should block production?
Items that affect core workflow, regulatory path, payment/locking behavior, safety-critical use or required connectivity should block production until resolved or formally excluded.
Tell us your workflow and rules.
We turn requirements into deployment-ready devices.