Android-SmartWebView wraps a website in a native shell you configure, not code

Configuration lives in swv.properties, not in Java

Android-SmartWebView is a WebView wrapper for building hybrid Android apps, and the design decision that shapes everything else is where the configuration lives. All of it sits in `app/src/main/assets/swv.properties`, and the documentation lists the property groups: `app.url` for the main URL the WebView loads, `offline.url` for the local page shown when there is no internet connection, `feature.*` for boolean toggles covering uploads, camera, zoom and pull-to-refresh, `plugins.enabled` for a comma-separated list of active plugins, `security.*` for SSL, screenshot blocking and third-party cookie controls, and `permissions.on.launch` for the permission groups requested at startup, `LOCATION` and `NOTIFICATIONS`. The code overview shows the same split: `SWVContext.java` loads the config and holds shared app state, `MainActivity.java` handles the WebView setup, the lifecycle and the feature wiring, and `PluginInterface.java` with `PluginManager.java` define the plugin contracts and registry.

Plugins are switched on by name

The plugin system is the part of the project that distinguishes it from a hand rolled WebView activity. Plugins are self-registering and modular, and the documentation is explicit that any plugin can be enabled or disabled from `swv.properties` without modifying Java source. In practice that means the `plugins.enabled` list is the switchboard, and a plugin that is not named there does not run. `PluginManager.java` is the registry and `PluginInterface.java` the contract, and `Playground.java` exists as a place to try plugins out. The reason this matters for a hybrid app is the usual pain point: the native capabilities a web app needs, camera, biometrics, location, sharing, are each a small amount of glue that every team ends up writing badly. Here they are written once, and the app decides which ones it wants from a configuration line.

Thirteen bundled plugins cover the usual hybrid app list

All plugins are free and included, and the catalogue is worth reading as a checklist for your own app. `AdMobPlugin` handles banner, interstitial and rewarded ads. `BiometricPlugin` handles fingerprint or face verification at launch or on demand, and `QRScannerPlugin` scans QR codes and barcodes through the device camera. `ImageCompressionPlugin` compresses images before upload to cut bandwidth. `JSInterfacePlugin` is the two-way bridge between JavaScript and native Android code, and `DialogPlugin` and `ToastPlugin` let JavaScript raise native alerts, confirmations and short toasts. `LocationPlugin` provides on-demand GPS with a 10-second timeout and automatic fallback to cached coordinates, served by `GeolocationCachePlugin`, which stores and serves those cached coordinates. `NetworkInfoPlugin` exposes the current connection state to the web app, `ClipboardPlugin` reads and writes the device clipboard, `SharePlugin` integrates the native share sheet, and `RatingPlugin` triggers an in-app review prompt from configurable usage counters.

Getting the project into Android Studio

The quick start is five steps and the first is a clone:

git clone https://github.com/mgks/Android-SmartWebView.git

From there you open the cloned folder through File, Open in Android Studio, configure `app/src/main/assets/swv.properties` and set `app.url` to your website's URL, optionally drop the `google-services.json` file from the Firebase console into the `app/` directory if you are using push, and then build with Build, Clean Project followed by Build, Rebuild Project. Push notifications are handled through Firebase Cloud Messaging and do require that `google-services.json` file, so it is the one step that is not optional for apps that want notifications. The repository root is a standard Gradle project with `gradlew`, `settings.gradle`, `build.gradle` and `gradle.properties`, and there is a `demo/` directory holding the web assets the app loads, including `index.html`, `script.js` and `style.css`, which is the quickest way to see the bridge working before you point it at a real site.

Security defaults, edge-to-edge and predictive back

The feature list covers the parts of a modern Android app that a WebView wrapper usually gets wrong. The app is described as secure by default, with SSL verification, screenshot blocking and third-party cookie controls, all configurable through the `security.*` properties. It supports Android's edge-to-edge window mode with proper inset handling, and predictive back on Android 13 and newer through `OnBackInvokedCallback`, which is a platform behaviour that a wrapper built on older assumptions can break. There are two custom UI modes, a fullscreen immersive layout and a standard navigation drawer layout, and network awareness is provided by `NetworkInfoPlugin` rather than by guesswork. Location is on demand with a 10-second timeout and an automatic fallback to cached coordinates, which is a sensible default for a web app that asks where it is, and the startup permission groups are declared in configuration rather than hard coded.

The same pieces are also published as standalone libraries

One of the more useful details in the README is that the core components are available separately, for any Android project that is not a Smart WebView app. There is a Biometric Gate library, a lifecycle-aware lock screen for any Activity, a File Handler for file uploads and camera captures in WebViews, a JS Bridge offering promise-based communication between Kotlin and JavaScript, a Print Helper for one-line printing in Android WebViews, and FCM Sync for syncing Firebase push tokens into WebView cookies. This changes how you would evaluate the project. If what you need is a promise-based JavaScript bridge or a camera upload handler rather than a whole hybrid app shell, you can take that one piece and leave the rest behind. The trade-off is that the split libraries carry their own release cadence, and the README does not pin their versions to the 8.x line of the main project.

An 8.x line with a wide release gap

The versioning tells you what kind of project this is. The tags are 8.0.3 on 2026-01-04, 8.1.0 on 2026-02-28 and 8.1.1 on 2026-09-23, and the last push to the repository was on 2026-10-01 with the repository not archived. So the project is on a stable 8.x line, but the gap between the 8.1.0 and 8.1.1 releases is about seven months, which is a release cadence driven by when the maintainer has time rather than by a schedule. The target platform moved too, with the documentation saying the app targets Android 17 at API 37 while keeping the minimum at Android 7.0, API 24, which is what the badge in the README shows. For an adopter, the practical questions are the minimum Android version your users actually have, since the floor is old, and how quickly you need a fix for a platform behaviour change on a recent Android release.

Editorial conclusion

Teams that need to ship a website as an Android app and want camera uploads, biometrics, location, sharing and push handled natively without writing their own bridge will find a lot of working code here, and the properties file means most changes need no Java edit. It is the wrong choice if you need fine grained control over the WebView internals or a plugin that does not exist, since the extension points are the plugin contract rather than a general API. Before adopting it, read the `swv.properties` file end to end, check the plugin list against what your product actually needs, and confirm your minimum Android version still fits the API 24 floor.

Frequently asked questions

Official sources

1. License: MIT
2. mgks/Android-SmartWebView on GitHub
3. Project website
4. README
5. Releases