getActivity/AndroidProject: a Java Android base architecture you clone instead of build

The problem AndroidProject solves: architecture work that repeats on every new app

Every new Android app begins with the same unpaid work. You pick a base Activity, wire a title bar, decide how dialogs are shown, add a network layer, write a toast wrapper, and settle on a package layout. None of that is the product, and all of it takes weeks before the first real feature appears. AndroidProject is a prebuilt answer to that phase. The README describes it as a "技术中台" (technology middle platform) and as "基建工程" (infrastructure engineering), and says it can be used for new project development or old project refactoring. It is written in Java and the repository is a Gradle project with an app module, a library module, and shared build files such as build.gradle, common.gradle and configs.gradle. The audience is the Android team that would otherwise copy files out of its previous app. The README states the project has been maintained for more than seven years, and the last push to the repository was on 2026-07-23, so the maintenance is current rather than historical.

What is actually inside the app and library modules

The repository is split so that reusable code and demonstration code are separate. The library module holds the parts you are meant to depend on. The app module is the sample: the README documents dozens of screens under 常用界面 (common interfaces) and 常用对话框 (common dialogs), plus animated demos, and these exist as screenshots and GIFs in the picture directory rather than as prose specifications. The topics list on the repository names the areas covered: baseactivity, dialog, glide, jetpack, mvi, mvp, mvvm, okhttp, popupwindow, recyclerview, retrofit, rxjava, titlebar and toast. Read that list carefully before adopting. It is a menu of what the project touches, not a promise that any single pattern is the recommended one. The README also states that the project has been put into production in multiple company projects and that no problems or bugs had been found at the time of writing, which is the author's claim about his own code, not an independent audit.

The startActivityForResult replacement is the most concrete design decision

The README singles out one mechanism as representative: AndroidProject changes how startActivityForResult works. In the stock Android API you pass a requestCode and override onActivityResult to receive the result. In AndroidProject you pass a listener object directly in the method call, the framework generates the requestCode for you, and onActivityResult checks it and dispatches the callback to the listener you supplied. The practical effect is that result handling lives next to the call that starts the activity instead of in a separate override. That is a real reduction in scattered state, and it is the kind of change that is hard to bolt on later, because once your team writes result handling the AndroidProject way, every new screen follows it. Treat this as the clearest example of the project's philosophy: wrap the platform where the platform's ergonomics are poor, and standardise the wrapper across the codebase.

Installing AndroidProject and running the sample app

The README does not give a step-by-step install procedure. It points readers at the GitHub repository and at a downloadable APK for release 13.1, and the repository itself is a standard Gradle project, so the normal route is to clone it and open the root in Android Studio. The commands below are the ones the repository layout implies: the Gradle wrapper is checked in as gradlew with gradlew.bat for Windows, and settings.gradle lists the modules.

git clone https://github.com/getActivity/AndroidProject.git
cd AndroidProject
./gradlew :app:assembleDebug

On Windows use gradlew.bat instead of ./gradlew. If the build succeeds, the debug APK is produced under the app module's build output directory. The repository does not document the minimum JDK or Android Gradle Plugin version in the README, so if the build fails on toolchain resolution, the versions to check are the ones declared in build.gradle, common.gradle and configs.gradle at the repository root.

To see the sample screens without building, the README links an APK for release 13.1. Note the version gap: the most recent release listed is 16.0 from 2025-12-23, while the linked APK is 13.1 from 2021-12-18, so the downloadable build does not represent the current source tree.

Where AndroidProject is the wrong choice

The README's own framing is the biggest warning. It says the project is a base for new development or refactoring and that it shortens the development cycle, and it presents itself as something you adopt wholesale rather than as a library you add to an existing architecture. If your team already has a settled architecture, adopting AndroidProject means replacing it, not extending it. The project is Java. The README links AndroidProject-Kotlin as a separate repository, which tells you the Java version is not the one to pick if your codebase is Kotlin. The topics list includes compose, but Compose is not the organising idea of the project; the base classes and the sample screens are built around the classic Activity and view system. There is also a maintenance surface to consider: the library wraps platform behaviour, and wrapped platform behaviour is exactly what breaks when a new Android version changes the rules. The README links a separate AndroidVersionAdapter repository for version adaptation, which suggests those fixes are tracked outside this repository. Finally, the README links HelpDoc.md for frequently asked questions, which is where the author has chosen to put known issues; the README itself does not document rollback or removal.

AndroidProject compared with starting from an empty Android Studio project

The realistic alternative is not another framework. It is the empty project Android Studio generates, plus whatever your team writes. The difference is where the decisions live. With an empty project, every convention is yours and every convention costs time: you write the base Activity, the title bar, the dialog helpers and the result plumbing before the first feature. With AndroidProject, those decisions arrive already made, reviewed over a long period, and demonstrated by sample screens you can run. The trade is control. An empty project has no inherited naming rules, no inherited package layout, and no wrapper around startActivityForResult that new hires must learn. The README's claim that the project shortens the cycle by nearly half is the author's estimate and should be treated as such. The honest comparison is: AndroidProject buys you weeks at the start and charges you in conventions for the life of the app.

Licence, maintenance and what an upgrade costs

The repository is licensed under Apache-2.0. That is a permissive licence, and it is the same licence family Android itself uses, which matters if you are already comfortable with Android's terms. This is not legal advice; read LICENSE in the repository and have your own counsel review it if the app is distributed commercially. On maintenance: the repository is not archived, and the last push was on 2026-07-23, so it is being touched. The release history is uneven rather than steady. Versions 13.0 and 13.1 landed in 2021, and the next listed release, 16.0, is from 2025-12-23. That is a long quiet period followed by a jump of three major versions. Plan upgrades as events, not as a drip: read the release notes for the versions you skip, and expect that a jump from a 13.x-based fork to 16.0 touches base classes your app subclasses. The README does not describe a migration guide, so the diff is your documentation.

Editorial conclusion

Adopt AndroidProject if you are starting a Java Android app or refactoring one and you want the common screens, dialogs and base classes already assembled, and you accept the project's naming and packaging conventions as your own. Do not adopt it if your app is Kotlin-first (the README points to AndroidProject-Kotlin), or if you need Compose as the foundation rather than as an optional topic. Before writing product code, open the app module and the library module and confirm which base classes you are expected to extend, check HelpDoc.md for the known issues, and verify the current release tag against your Android Gradle Plugin and compileSdk versions.

Frequently asked questions

Official sources

1. getActivity/AndroidProject on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases