Easy Diary is a GPL Android diary with 171 themes, postcards and Google Drive backup

A diary that stays on the device and keeps its entries in an embedded database

Easy Diary is described as a diary application optimized for the best user experience, and the primary language is Kotlin. The interesting structural decision is what it does not ask for. There is no account to create, no server to trust and no subscription, and the app is published on Google Play and on F-Droid, which is the distribution pair you would expect from an application that keeps its content locally.

The topic list names an embedded object database alongside android, kotlin, calendar and diary, and that choice shapes the rest of the design. Storing objects directly rather than rows that you map means the diary entries, the attached photos and the metadata are objects the UI can read without a conversion layer in between.

The application id is visible in the download links, me.blog.korn123.easydiary, and the repository is hanjoongcho/aaf-easydiary, with the prefix aaf shared across a family of small applications by the same author: the star history badge in the README references aaf-easydiary, aaf-easyphotomap and aaf-easypassword together, which is a hint that this is one entry in a series rather than a one-off.

The licence is GPL-3.0, the default branch is master, and the last push was on 2026-10-20. The release history has an odd shape worth noting: v1.4.142 from 2020-08-22, then v1.4.351.202609300 from 2026-09-30 and v1.4.352.202610020 from 2026-10-02. The old tag follows a plain three-part version, and the current ones carry a four-part number with a date appended, so the numbering scheme changed at some point and the two eras are not directly comparable.

The feature list, and the parts that are unusual for a diary

Writing and editing with the keyboard or voice recognition is the core, and search comes next: quickly retrieve saved entries, with matching keywords highlighted for easy identification. The highlighting detail is what makes search usable in a diary, where you remember roughly what you wrote rather than the exact string.

The viewing modes are three: a calendar to see entries organised by date using the built-in calendar, and a timeline to browse entries in chronological order. The calendar also has a configurable start day, and the README shows a preview video for it, which suggests it is a setting people change.

Then there are the features that are not standard. Diary Postcards let you create postcards using your entries and photos to share with friends, described as suitable for anniversaries or holiday greetings. That is a sharing feature in a private diary app, and it is the one that raises the obvious question about what a shared postcard contains.

Lock is a PIN or fingerprint recognition, so the diary can be protected at the device level rather than relying on the phone's own lock. Application Themes offers 171 colour themes plus a colour picker to customise text and background colours. Fonts supports custom TTF fonts, and the mechanism is simply to add them to the Easy Diary font directory to use them in the app, which means no import flow and no per-file settings, just a directory you watch.

Charts visualise your diary writing habits over time with bar charts, so the app reports on your own consistency rather than only storing what you wrote. Backup and Restore securely backs up and restores all content, including attached photos, using Google Drive.

One feature is listed but not explained anywhere in the README: an Easter Egg labelled Custom Symbols, shown in the previews section. The project also carries a set of preview videos dated 2018 to present covering the overview, themes, markdown syntax, a welcome dashboard popup, attached photo highlights, location information display, an optimized card view design, calendar start day, font settings, Google Drive integration and that Easter Egg, plus a set of classic screenshots from before 2018.

Distribution, privacy policy and the documentation split

The README is mostly a feature list and a gallery, which is normal for an application, but the non-feature parts are where the engineering information is.

Distribution is three ways. You download the latest APK from the Releases page, or you install from Google Play, or you install from F-Droid. The Play Store badge points at me.blog.korn123.easydiary and the F-Droid badge at the same package on f-droid.org.

Privacy is handled as a separate document, with an Easy Diary Privacy Policy page hosted at hanjoongcho.github.io/aaf-easydiary/Privacy, and the repository also carries a Privacy.md alongside Privacy_ko.md, which is the Korean version. The fact that the privacy policy is a hosted page rather than a file in the repository suggests it changes independently of the code, which is the normal arrangement when the policy is about the distributed app rather than the source.

Documentation is split three ways and the split tells you what each is for. There is a Developer Documentation link pointing at ./docs/README.en.md, which is where an engineer looking at the code should start. There are user manuals, and the README notes that as of 2023 they are available on Notion and YouTube, with a link to a manual v0.1. The move of the manuals off the repository and onto Notion and YouTube is itself informative: the audience for the manual is an end user rather than a developer, and video walkthroughs suit that better than a file in the source tree.

The repository top level also shows the shape of the project: an app/ directory for the Android application, data/ and metadata/ directories, a docs/ directory, a build.gradle.kts and settings.gradle.kts with a gradle.properties, a gradle wrapper with gradlew and gradlew.bat, a gradle/ directory, an .editorconfig, and a set of localised documents. That last group is worth noting: FAQs.md, FAQs_ko.md and FAQs_zh_rcn.md, plus README.md and README_ko.md and Privacy.md and Privacy_ko.md, and the third-party licence file THIRDPARTY.md that the licence badge points at.

So the localisation is done at the repository level for the documentation and, per the README, in the app itself with a full interface in English and Simplified Chinese elsewhere in the project family. The FAQ files exist in English, Korean and Simplified Chinese.

Building the GMS flavour, and the signing key you have to supply

The build section is short and has one prerequisite that catches people out: the GMS, Google Mobile Services, flavour needs Google project settings configured and the weather icons imported manually from Flaticon.

The steps as the README gives them:

Step 1. Fork or download the 'aaf-easydiary' project.
Step 2. Import the project into Android Studio.
Step 3. Configure 'storeFile' and 'storePassword' in your 'local.properties' file.
       +++++++ local.properties +++++++++++++++++++++++++++++++++++
       storeFile=your signing key location
       storePassword=your password
       ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
       +++++++ example ++++++++++++++++++++++++++++++++++++++++++++
       storeFile=C:/dev/android/app-signing.jks
       storePassword=sjdiSDAss3!@#
       +++++++++++++++++++++++++++++++++++++

The step three detail is the whole of it. Signing a release build needs a keystore, and the keystore path and password go into local.properties rather than into a tracked file, which is the correct arrangement and the reason the file is in the gitignore. The example values show the shape of the expected entries: an absolute path to a .jks file and the matching password.

Two things follow from the instructions being this short. There is no documented Gradle command line for building, so the build is driven from Android Studio, which is the normal path for an application that needs a signing key. And there is no documented test step, so the verification story for a change to this code is whatever the IDE gives you rather than a documented suite.

The build.gradle.kts and settings.gradle.kts at the root, with the Gradle wrapper checked in, mean the Gradle version is pinned by the wrapper rather than by whatever happens to be installed, which is the part of the setup most likely to work on a fresh machine.

Where Easy Diary is the wrong choice

Three limits, and the first is about what a diary app with a Google Drive backup actually promises.

The first is that backup goes through Google Drive, which means the privacy story depends on a Google account even though the app itself does not require one. The feature list says the backup and restore covers all content including attached photos, using Google Drive, and there is no mention of an alternative backend or of an end-to-end encrypted local archive. For a diary, which is the kind of application people put the most sensitive writing in, the combination of a lock feature and a cloud backup raises the question of what protects the backup at rest, and the README does not answer it. The separate privacy policy page is where that answer should be, and it is worth reading before you trust the app with anything you would not want in a photograph.

The second is that the development documentation is not in the README. The developer documentation link points at a guide in the docs/ directory, and the README itself describes features rather than architecture. So if you want to fork this and change it, you start with the guide, not with the README, and the guide is not part of what the README covers. There is also no documented test command and no documented command line build, so getting a working development environment is a step the README does not walk you through.

The third is the release version scheme. The tag list shows v1.4.142 from 2020 and then v1.4.351.202609300 and v1.4.352.202610020 from September and October 2026. Whatever the numbering means, it is not a semver, and the gap between the two shapes of version number means you cannot tell from the tag alone which code is in front of you. The tags are also not present for most of the 2020 to 2026 period, so if you need to identify which build a user is running from a bug report, the version string is the only handle and it has to be parsed.

The alternative approach is a plain text diary kept in a file you control, or a note-taking application whose data model you can export without an app-specific backup format. The difference in approach is that Easy Diary gives you a designed writing experience with search, themes, charts and a calendar, all of which you would otherwise build or accept missing, at the cost of the data living in an application-specific store that you can only move with the app's own backup or restore. For someone who wants the writing experience and is comfortable with the storage arrangement, it is a good fit. For someone whose diary is a text file they can grep and re-home, it is the wrong shape.

Editorial conclusion

Adopt Easy Diary if you want a diary on Android with no account, no subscription and source you can read, because the whole app is GPL-3.0 and published as an APK as well as through two stores. Do not adopt it as a base for your own application without reading the licence and the build steps, because the GMS flavour requires Google project configuration and a manually imported icon set, which is friction a generic starter does not have. Verify first that the release you install matches the build you are looking at, since the version scheme combines a build number with a date and the tags jump from 2020 to the current numbering, that the Google Drive backup path you rely on is the one the current release uses, and that the developer guide at docs/README.en.md covers the area you are changing, since the README itself points there rather than documenting the architecture.

Frequently asked questions

Official sources

1. hanjoongcho/aaf-easydiary on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases