Getting started with Droid Builder
Stamp a native Android app from the same kind of options file.
Droid Builder stamps a native Android application from three things: a shared template, an options / metadata file, and an app-specific extender. This page is the short path from those repos to a project Android Studio can open.
The server-side twin is Getting started with WildFly Builder. The idea behind both is What is a software factory?.
What you need
Android Studio (or at least the Android SDK and a JDK the project’s Gradle wrapper accepts).
Git.
The Droid Builder source. The builder page on this site links the Git repository: https://sw-builder.com/appstore/builders/apps/droid-builder.html
One catalog app to stamp first. Booklet, Social, and Security on the Android side are the current product line: https://sw-builder.com/appstore/android/
The mental model
template/ is the base Android framework: activities or fragments the line always has, Gradle files, the navigation shell.
build/ holds reusable Java fragments declared in XML (APP_CODES, APP_FUNCS, APP_PROCS). That is the parts bin.
An extender such as BookletExtender selects those fragments and applies them onto the template.
You do not design the car from scratch. You pick the options. The factory stamps the product.
Build scripts live in each generated app repo, not in the builder. A typical script pulls Droid Builder, overlays template/ and build/, runs DroidBuilder and the extender, then you assemble the APK the way you would any Android app.
Stamp a first app
1. Clone Droid Builder and one Android catalog app side by side.
2. Open the options / metadata in the app repo. That is the contract: entities, field types, names.
3. Run the app’s stamp script — the one that overlays template/ and build/, then runs DroidBuilder plus the extender.
4. Open the generated project in Android Studio.
5. Sync Gradle. Fix only environment issues (SDK path, JDK, build tools version). Do not “clean up” generated packages until you have a running build.
6. Install on an emulator or device.
You now have a phone-side cousin of the WildFly app with the same product name. That is the point of the two factories.
What “done” looks like
Android Studio imports the project without a missing-module failure.
The screens the extender promised exist. For Booklet that is the read / browse flow around books and pages. For Social it is people, posts, follow / browse.
The domain names match the options file, not a one-off redesign in Java.
You can change an option, run the factory again, and rebuild.
Keep the two chassis in sync
When you add a field on the WildFly Booklet, add it on the Android Booklet options too. The factories do not magically share a database. They share a vocabulary. Sync is possible because the models stayed cousins.
If you only ever stamp one stack, you still get a working Android app. You just lose the “same recipe, two cars” story this site is built on.
Where the rest of the notes live
Per-app Gradle flags, signing, and emulator notes stay in that app’s repo. This page is the shared path so a visitor can learn the factory on sw-builder.com instead of only on GitHub.
Catalog: https://sw-builder.com/appstore/android/
Builder: https://sw-builder.com/appstore/builders/apps/droid-builder.html