UUID API
Identify app installations with a unique UUID appended to your WebView URL or retrieved via JavaScript.
The WebViewGold UUID API allows you to retrieve a non-personal, unique device ID (UUID - "Universally Unique Identifier") via JavaScript, which can uniquely identify an Android device. This feature can be helpful for:
- Storing user-specific settings on the server
- Maintaining session states
- Recalling saved data on the client side
Privacy Note: Ensure compliance with local and international privacy laws when using this feature, as it involves device identification.
How to Retrieve UUID:
To retrieve the UUID from your WebView-based app, use the following code:
<a href="get-uuid://">Get UUID</a>
<a href="#" onClick="alert(uuid);">Show UUID</a>
- Get UUID: Requests the UUID from WebViewGold.
- Show UUID: Displays the UUID via an alert for easy testing.
Alternative Method: Append the UUID to the WebView URL
If you prefer to include the UUID in the URL parameters, enable the UUID_ENHANCE_WEBVIEW_URL option in Config.java by setting it to true. This will automatically append uuid=XYZ to your WebView URL on the first request, allowing you to access the UUID directly in your web content:
- Example: If your WebView URL is
https://www.example.org, it will be requested ashttps://www.example.org?uuid=XYZ. - Note: Only the initial URL request will include this GET parameter, so consider saving it in a session or cookie if you need to reference it later in the app.
Automatically Inject UUID into JavaScript:
To automatically make UUID (and other variables) available in JavaScript across all pages without modifying URLs, set AUTO_INJECT_VARIABLES to true in Config.java. This allows you to access the UUID and other values directly within any page.
SDK-style implementation notes
Treat this feature as a native capability exposed to your web layer: keep your production website or PWA as the source of truth, then use the documented WebViewGold configuration flags, URL commands, and JavaScript bridge calls to opt in to native Android behavior only where it adds value. This approach keeps your codebase maintainable because the same web application can serve browsers, WebViewGold for Android, and the other WebViewGold platforms with minimal conditional logic.
For reliable results, prefer HTTPS endpoints, stable route names, explicit success/error states in your UI, and small JavaScript helper functions that wrap native calls. For example, a web app built with jQuery Mobile, Lovable, Base44, Bolt, WordPress, Bubble, a custom React/Vue/Angular stack, or static HTML can expose a single button or event handler that triggers the native WebViewGold API while still showing a graceful browser fallback.
- Recommended integration pattern: detect the app context, call the WebViewGold API, then update your web UI after the native callback or route change.
- Testing checklist: validate the feature on a real device or packaged build, verify permissions and store review text, and confirm that browser-only users still receive a useful fallback.
- SEO benefit: keep feature pages, route titles, and structured content indexable on your website while WebViewGold delivers the native app shell for Android users.