# Aves: an Android gallery built around metadata, not just thumbnails > Aves is a Flutter gallery and metadata explorer for Android. It reads EXIF, XMP, TIFF, GeoTIFF, GPX, motion photos and more, and it ships through Google Play, F-Droid, IzzyOnDroid, Obtainium and GitHub releases. **deckerst/aves** — Aves is a gallery and metadata explorer app, built for Android with Flutter. - Repository: https://github.com/deckerst/aves - Stars: 5,328 · Forks: 237 - Language: Dart - License: BSD-3-Clause - Published: 2026-09-22 · Updated: 2026-09-22 · Language: en - Canonical page: https://hysenlabs.com/projects/deckerst-aves ## What Aves solves for people with messy media folders Most Android galleries assume your library is JPEG and MP4 and that a thumbnail is all you need. Aves starts from the opposite assumption. The README states it can handle "multi-page TIFFs, SVGs, old AVIs and more", which is a way of saying the app was written for libraries that accumulated files over years and across devices. The audience follows from that: people who still have scans, exported panoramas, GeoTIFF captures or camera formats that a stock gallery renders as a broken icon. The second problem is metadata. Aves scans a collection to identify motion photos, panoramas (the README calls them photo spheres), 360 degree videos and GeoTIFF files. That scan is not a side feature. It is what lets the app group a motion photo's still and its video, or place a photo sphere on a map instead of showing it as a flat rectangle. If you only ever shoot single JPEGs, the scanning work buys you little. ## How the app is structured and where the metadata comes from Aves is a Flutter application targeting Android. The repository layout reflects that: lib/ holds the Dart code, android/ the platform shell, plugins/ and flavors/ the build variations, and assets/ the bundled resources. The build tooling is not plain Flutter either. There is a flutterw wrapper script and a pubspec.yaml with a committed pubspec.lock, so the project pins its dependency graph rather than resolving it fresh on every build. The data flow described in the README is scan, then navigate. A media scan service runs in the foreground, which is why the permission table lists FOREGROUND_SERVICE, FOREGROUND_SERVICE_MEDIA_PROCESSING, POST_NOTIFICATIONS and RECEIVE_BOOT_COMPLETED under "media scan service feedback". The app reads your collection through READ_MEDIA_IMAGES, READ_MEDIA_VIDEO and READ_MEDIA_VISUAL_USER_SELECTED, and reads location metadata through ACCESS_MEDIA_LOCATION. Writing back to the collection uses MANAGE_MEDIA. Network access is narrower than people assume. INTERNET is listed for "map view, reverse geocoding" only, and ACCESS_NETWORK_STATE plus ACCESS_WIFI_STATE support the scan service. There is no account, no sync and no cloud component in the permission table. ## Installing Aves and reading your first file's metadata There is no build step to run for normal use. The README offers five distribution channels: Google Play, IzzyOnDroid, Obtainium, F-Droid and GitHub releases. The F-Droid package identifier is deckers.thibault.aves.libre, which is the libre flavor rather than the Play build, and the repository keeps a flavors/ directory for exactly that split. If you prefer the release artifacts, the GitHub releases page carries the latest build, currently v1.15.4. Obtainium users can point the app at the repository URL directly, which the README's Obtainium badge encodes as a redirect into the app: ```bash # Obtainium deep link encoded in the README badge https://apps.obtainium.imranr.dev/redirect.html?r=obtainium://add/https://github.com/deckerst/aves ``` Once installed, the first useful action is not browsing. Open a file you already know is unusual, a multi-page TIFF or a GeoTIFF, and open its info panel. The README's screenshots show two separate info views, one basic and one for metadata, so expect the metadata view to be the one that carries the EXIF and XMP fields. If a file renders as a thumbnail but the metadata panel is empty, that is the case worth reporting. For contributors who do want to build from source, the repository provides the flutterw wrapper instead of a bare flutter command: ```bash ./flutterw pub get ``` The README does not document the remaining build steps, so treat the wrapper as the entry point and read scripts/ and the flavor directories before assuming a single build command produces every variant. ## Where Aves is the wrong tool The README is explicit that the project does not accept pull requests at this stage. That is a real constraint, not a formality. If your reason for choosing an open source gallery is that you intend to fix a rendering bug yourself and ship it, Aves will not take the patch. Bug reports and feature requests go through issue templates, and the README points to a guidelines thread that it says you should read first. Questions go to discussions instead. The platform boundary matters more. Aves is built for Android with Flutter, and the README mentions Android TV integration but no other platform. There is no iOS, desktop or web target described. If your library lives on a NAS and you want a viewer on a laptop, this is the wrong project regardless of how well it handles TIFF. The permission set is also larger than a minimal viewer's. USE_BIOMETRIC and USE_FINGERPRINT exist for vault lock, SET_WALLPAPER for wallpaper setting, WAKE_LOCK for keeping the screen on. Each is tied to a named feature in the table, but a user who wants a gallery that does nothing else will find the surface broader than expected. ## Aves compared with Fossify Gallery Fossify Gallery appears in the searches people run around this project, and the two take different positions on the same problem. Fossify Gallery is a general purpose Android gallery in the lineage of the older Simple Mobile Tools apps: the goal is a clean replacement for the stock gallery, with the usual album, folder and editing operations. Aves' README describes something narrower and deeper, a metadata explorer that happens to render media. The practical difference shows up in what each app does with an odd file. A gallery built around browsing will show a TIFF, a GeoTIFF or a motion photo as best it can and move on. Aves scans the collection specifically to identify motion photos, panoramas, 360 degree videos and GeoTIFF files, which means those formats get a category and a viewer rather than a fallback. The reverse is also true: if you want a lightweight gallery with no metadata layer, no map view and no vault, the extra machinery in Aves is overhead you will not use. ## Maintenance cadence, licence and upgrade cost The last push to the develop branch was on 2026-09-22, and the most recent release, v1.15.4, is dated the same day. Two earlier releases, v1.15.3 and v1.15.2, landed on 2026-09-09. That is a steady release rhythm, and the repository is not archived. Upgrades are cheap for users because the app has no server component. There is no database migration to run and no config file to edit; the changelog lives in CHANGELOG.md and the README links to a wiki page for comparing app versions. The cost sits with anyone building from source: a Flutter toolchain, the flutterw wrapper, and a pinned pubspec.lock mean you rebuild rather than patch a binary. Aves is licensed BSD-3-Clause. That is a permissive licence, so redistributing a modified build is allowed under its terms. I am not a lawyer and this is not legal advice. One thing worth noting is the flavor split: the F-Droid listing uses the package deckers.thibault.aves.libre, so the libre build and the Play build are distinct artifacts with distinct identifiers, and redistribution questions should be checked against whichever flavor you are handling. ## Conclusion Adopt Aves if you keep a mixed media library on Android and want the file metadata visible rather than hidden, and if you accept that the project does not take pull requests and that bug reports go through a guidelines thread first. Do not adopt it if you need an iOS or desktop viewer, or if you expect to patch the Dart source and have it merged upstream. Before installing, verify which distribution channel matches your device: the README lists Google Play, IzzyOnDroid, Obtainium, F-Droid (package deckers.thibault.aves.libre) and GitHub releases, and the permissions table shows INTERNET is only requested for the map view and reverse geocoding, so a build without maps would not need it. ## FAQ ### What is the best free gallery app for Android? That depends on what you need, but Aves is a free gallery app for Android that the README describes as handling JPEGs and MP4s plus multi-page TIFFs, SVGs and old AVIs. It is distributed through Google Play, IzzyOnDroid, Obtainium, F-Droid and GitHub releases, and the source is licensed BSD-3-Clause. ### Is there an open source gallery app for Android? Aves is one, licensed BSD-3-Clause and developed in the open on GitHub under the deckerst/aves repository. Note that the README states the project does not accept pull requests at this stage, so contributing code is not currently an option even though the source is public. ### Is there a gallery app for Android available on GitHub? Yes. Aves lives at deckerst/aves on GitHub, with the develop branch as the default, and the README links to a GitHub releases page as one of its five install channels. The repository is not archived and the last push to develop was on 2026-09-22. ## Sources - [deckerst/aves on GitHub](https://github.com/deckerst/aves) - [Issues](https://github.com/deckerst/aves/issues) - [License: BSD-3-Clause](https://github.com/deckerst/aves/blob/develop/LICENSE) - [README](https://github.com/deckerst/aves/blob/develop/README.md) - [Releases](https://github.com/deckerst/aves/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/deckerst-aves