Nomid(Managed Google Play web apps model through EMM)
1. Purpose
This manual explains, from both an operational and conceptual perspective, how to create, configure, and make available a Web App in Managed Google Play through the EMM/Nomid MDM flow, without publishing a public app in Play Store.
This model:
- Does not use an APK or AAB
- Does not use Android Studio
- Publishes a URL as a private app for the organization in Managed Google Play
- Can be distributed by policy in Nomid MDM
This manual does not cover PWA + TWA or native Android applications.
To turn a shared route link into an individual Web App, see Create a Web App for a Google Maps route. The guide explains how to create and test the route, register the link, distribute Maps and Chrome, and validate the shortcut on the device.
2. What is a Web App in Managed Google Play?
A Web App is an application that:
- Opens an externally hosted URL
- Is installed through managed Play Store when distributed by policy
- Uses the selected display mode to present the URL content
It should be understood as:
A website installed as an application, not a traditional Android app.
3. Prerequisites
| Item | Required |
|---|---|
| Public URL | Yes |
| Valid HTTPS | Yes |
| Mobile-friendly website | Yes |
| 512 x 512 icon | Yes |
| Managed Google Play access through the EMM/Nomid | Yes |
4. Path in Managed Google Play
To create the Web App and associate it directly with a policy, use the confirmed path:
Nomid MDM > Policies > select the policy > Home Screen > Add App > Create Web App
This path opens the creation form in the context of the policy that will distribute the shortcut. Other screens may show application catalogs or records, but they should not be treated as an equivalent path unless the flow displayed in the portal has been confirmed.
5. "New Web App" screen
5.1 Title
The application name displayed in the Play Store.
Best practices:
- Use the product's real name
- Avoid misleading terms such as "official" or "system"
5.2 URL
The initial URL opened when the application starts.
Rules:
- Must begin with
https:// - Must not use HTTP Basic Authentication
- Application-level login is allowed
5.3 Display mode
Full screen
Completely removes the browser interface.
Effect in use: provides a more immersive presentation but leaves fewer visible controls for checking the address, refreshing the page, or returning during troubleshooting. Validate return, authentication, and navigation on the pilot device before adopting this mode.
Standalone
An intermediate mode.
Effect in use: presents the content in a separate window with the device bars but without the full URL bar. Certify this mode when return and navigation work without additional controls.
Minimal UI (recommended)
Displays:
- Status bar
- Navigation bar
- URL bar and refresh button
Why use it:
- Makes it easier to check the opened address
- Keeps refresh and return controls visible during testing
- Helps diagnose redirects and loading failures
Use Minimal UI as the starting point for the first pilot, not as a universal requirement. After testing, the organization may certify another mode. The mode controls Web App presentation; by itself, it does not determine which application opens an external link.
5.4 Icon
Requirements:
- 512 x 512 pixels
- PNG or JPG
- Square and maskable
An incompatible file may prevent registration from being completed or make the application difficult to recognize. Confirm dimensions, format, and readability before selecting Create.
6. Best practices
6.1 Use Minimal UI
Why: this mode keeps visible controls that help verify the address, refresh content, and return during the pilot.
What it lets you validate:
- Expected URL and redirects
- Content refresh
- Return and navigation on the device
6.2 Avoid excessive redirects
Why: each redirect may take the user to another domain or authentication flow. Test the complete path in the Web App before distribution.
Risks:
- Login loops
- Blank screen
- Application failing to load
6.3 Test login in Chrome for Android
Why: testing in Chrome for Android helps identify layout, redirect, and authentication issues before creating the Web App.
Practical rule: the Chrome test is preparation, not certification. Repeat the flow in the Web App and on the pilot device.
6.4 Ensure a good mobile experience
Why: a page designed for mobile screens reduces touch, reading, and navigation errors on the device.
Common problems:
- Small buttons
- Inaccessible menus
- Unusable tables
7. Limitations and their impact
Android Enterprise APIs
It is not possible to:
- Apply per-app policies
- Send managed configurations
- Control behavior through the MDM
Everything must be controlled through the web backend.
Device Owner
It cannot:
- Control the device
- Lock the system
- Operate as a real kiosk
Managed Configurations
It does not receive parameters from the MDM.
Alternatives:
- Configuration through login
- Profile by user or company
Zero-touch
It does not participate in the initial Android provisioning flow.
Native APIs
It cannot access:
- USB
- Classic Bluetooth
- Specialized hardware
Only browser-supported APIs are available.
8. Pre-publication checklist
8.1 URL
- [ ] Valid HTTPS
- [ ] Opens without errors
- [ ] No HTTP authentication
- [ ] No redirect loop
8.2 Login and session
- [ ] Works in Chrome for Android
- [ ] Cookies persist
- [ ] Logout works
- [ ] Session does not expire immediately
8.3 Navigation
- [ ] Back button works
- [ ] External links open correctly
- [ ] Errors are handled
8.4 Store listing
- [ ] Consistent name
- [ ] Realistic description
- [ ] Genuine screenshots
- [ ] Correct category
8.5 Privacy policy
Required when there is:
- Login
- Cookies
- User data
8.6 Data Safety
Review with the technical team:
- [ ] Data collected
- [ ] Storage
- [ ] Sharing
- [ ] Encryption
- [ ] Data deletion
9. Publication
- Review every checklist item and confirm title, URL, display mode, icon, and privacy policy when applicable.
- Save/create the Web App in the Managed Google Play flow provided by Nomid.
- Wait for Managed Google Play propagation; publishing usually takes a few minutes, but updates may take longer to appear on every device.
- Add the Web App to the policy as Optional or Required, publish the policy, and validate on a pilot device.
Deleting the Web App from the catalog removes future distribution, but it does not replace access revocation in the web system. If the site must no longer be accessed, also block or remove access in the application backend.
10. Conclusion
This model is suitable for:
- Web portals
- Dashboards
- Administrative systems
It does not replace:
- Native Android applications
- MDM/EMM solutions