Frames: an Android dashboard library for wallpaper apps

A dashboard for wallpaper apps, distributed as a library

Frames is not a wallpaper app you install. The project description calls it a free, feature-rich, easily customizable Android dashboard for wallpapers apps, and the README is explicit that it is included in your project as a dependency through Maven. The repository therefore contains two things: an app/ directory that is a working sample, and a library that other wallpaper apps embed.

The topics list makes the intent clearer still, with android-dashboard-library, android-library, dashboard, template and wallpapers among the tags. The API badge reads 21+, and the feature list says it works with Android 5.0 and newer, which are the same statement. The primary language is Kotlin, and the build setup at the root uses build.gradle alongside settings.gradle.kts, a gradle/ directory, a gradlew wrapper and a buildSrc/ directory.

That shape makes sense for a project with a reference implementation attached. A sample app shows how the dashboard is wired into an actual wallpaper app, and the library gives you the same dashboard to embed. The download link in the README points at a sample app hosted outside the repository, and a separate link offers support to the author.

The audience is Android developers with a wallpaper or image-centric app who want a front end they can ship quickly. The companion site for the project is dashbud.dev, and the implementation guidance is in the repository wiki rather than in the README, which is the first place to look if you are trying to use it.

What the dashboard gives you and what it assumes

The feature list is the best description of the library you will get, because the README documents the dashboard rather than the internals.

Structurally, you get a Material Design dashboard with a categories section, a favorites section, a credits section and a settings section. Wallpapers can be applied and downloaded, and there is a full-screen viewer with zooming and a detailed info viewer, with several themes for it. Settings cover changing the app theme with Light, Dark, System and AMOLED options, coloring the navigation bar on Lollipop and newer, and clearing the app cache. Tablet layouts are included.

Two features are about a commercial model rather than about the interface. There is a license checker and there is donations. And OneSignal notifications are described as ready, which means the integration points exist rather than that push messaging is configured for you.

One assumption is worth flagging before you adopt it. The README states that the wallpapers are cloud based, only. A dashboard that resolves items from a remote source behaves differently from one that lists local files: the categories and favorites structure depends on a catalogue on a server, and the offline support listed under the features is what carries the experience when the network is not there. If your app's content is local, or your backend is not a simple image catalogue, the library gives you a shell rather than a finished product.

Adding Frames to a Gradle project

The README calls the setup simple, and it is two edits to your build files. The first step is to make the repositories available in your root build.gradle file, adding MavenCentral and Jitpack:

allprojects {
    repositories {
        mavenCentral()
        maven { url 'https://jitpack.io' }
    }
}

The second step is the dependency itself in your project build.gradle file:

dependencies {
    implementation('dev.jahir:Frames:{latest version}@aar') {
        transitive = true
    }
}

You are expected to replace the placeholder with the published version, and the README points at the GitHub releases page for the current one. The newest tags are 3.8.0 on 2026-10-07, 3.7.1 on 2025-12-24 and 3.7.0 on 2025-08-15, so the versions move in the 3.x line.

Two details in that snippet carry weight. The artifact is an AAR rather than a JAR, because it includes Android resources, layouts and the theme the dashboard uses. And transitive is set to true, so the library's own dependencies come along rather than leaving you to resolve them by hand.

The README does not document how the dashboard is then attached to your activities, what callbacks you implement, or which of the feature modules can be switched off. All of that is in the wiki, which the README points to as the place with everything you need to know about implementation. Budget time for that, because the library gives you screens and you still have to wire them.

The sample branch is the working reference

The default branch of this repository is named sample, which is a small detail with a large implication. What you land on when you clone the project is a working application rather than a bare library skeleton, and that application is the fastest way to understand the intended integration.

The repository root shows the shape of a modern Android build: .github/ for automation, .idea/ for IDE settings, app/ for the sample module, buildSrc/ for custom build logic, gradle.properties for build configuration, a gradle/ directory, the gradlew and gradlew.bat wrapper scripts, settings.gradle.kts for module settings and build.gradle at the top level. The sample module is where the wiring lives, which is why reading it is faster than reading the wiki when you want to know how the dashboard is embedded.

The sample app is also distributed outside the repository through the download link in the README, so you can see the finished result on a device before you commit to the dependency. A linked page lists other apps built using this dashboard, which is a reasonable way to judge how flexible the library is in practice.

The build workflow is wired through GitHub Actions, and the badge in the README points at a build workflow for the sample branch, so a passing build on that branch tells you the sample still compiles against current tooling. The repository also carries a Crowdin project for translations, and the README asks for help translating, so localisation of the dashboard strings is community-driven rather than something you would add to your own build.

A ShareAlike licence inside a commercial app

The licence needs attention, and it needs attention precisely because this is a template you embed in a product.

The README states the project is shared under the Creative Commons Attribution-ShareAlike licence, with the copyright line reading Copyright 2020 Jahir Fiquitiva and a reference to the Creative Commons Attribution-ShareAlike 4.0 International legal code. The GitHub metadata for the repository, however, classifies the licence as a custom one that GitHub cannot classify, which means the LICENSE.md file at the root is the authoritative text and it may not match the README summary.

Two practical consequences follow, stated without offering legal advice. First, an attribution and share-alike licence written for a creative work is an unusual fit for a code dependency embedded in an application, and the obligation it places on a derived work is not the same as what an MIT or Apache-2.0 dependency would ask of you. Second, the discrepancy between what the README says and what the repository metadata says means you should read LICENSE.md in full rather than rely on the summary line.

The version of the Creative Commons licence named in the README is 4.0 International, published as the CreativeCommons Attribution-ShareAlike licence. That is the term to evaluate. If your application is closed source, or your company has a policy against share-alike obligations, this is the point in the evaluation where you stop and check, not after you have shipped.

Release cadence and the alternative of building your own dashboard

The version history suggests the project is still moving. Tags land at 3.7.0 on 2025-08-15, 3.7.1 on 2025-12-24 and 3.8.0 on 2026-10-07, and the last push was on 2026-10-07, the same day as the newest release. The repository is not archived. Whatever else is uncertain about the licence, the code is being maintained.

The alternative is to build the dashboard yourself, and for many wallpaper apps that is the right call. Writing it means Material Design components under your own design system, your own data layer over whatever source your app uses, your own favorites and category storage, your own full-screen viewer, and no licence to reconcile. The cost is the work: a dashboard with categories, favorites, a viewer with zooming, tablet layouts, theme switching including AMOLED, offline behaviour and download plus apply actions is a lot of screen work before you reach the actual wallpaper feature.

Frames flips that trade. You accept the ShareAlike terms, the cloud-only wallpaper assumption, the bundled license checker and donations sections, and a dashboard whose look you did not design, in exchange for a working front end on day one. Teams building a wallpaper app as a side project usually take that deal. Teams building a product with a brand, a proprietary content source and a legal review step usually do not.

Editorial conclusion

Frames fits an Android developer who is building a wallpaper app and would rather ship a finished Material Design dashboard than design one, and who can work inside a ShareAlike licence and a library that expects its wallpapers to come from a cloud backend. It is the wrong choice for an app with its own established design system, for a project that needs a different content model than cloud-only wallpapers, or for a team unwilling to take on the licence terms, since the README states the project is shared under Creative Commons Attribution-ShareAlike 4.0 while the repository is filed under a licence GitHub cannot classify. Before depending on it, read LICENSE.md, pin the version you tested from the releases page, and confirm that the JitPack coordinates dev.jahir:Frames resolve for your build setup.

Frequently asked questions

Official sources

1. Issues
2. jahirfiquitiva/Frames on GitHub
3. Project website
4. README
5. Releases