Android Cookbook Examples: a hundred and fifty sample projects from a published book

The first line of the README is a warning, and it is the right one

The README opens with a note that says a lot of this stuff is out of date now, and everything else in the document follows from that admission. The repository is described as being among the largest collections of Android code samples anywhere, containing around a hundred and fifty source code examples from the O'Reilly Android Cookbook, which was at the time of its publication a great source of tutorial material for the Android developer. The primary language is Java, the homepage is androidcookbook.com, and the licence is a custom one in the LICENSE file that GitHub cannot classify. The value of the collection is therefore not as a current reference implementation but as a record of how things were done, and a reader who knows the era of the APIs in a given directory can judge for themselves.

The samples are not a tutorial, and the README says which ones are missing

The README is careful about what the collection is not, and that honesty is useful. Not all recipes in the book or online have code accompanying them, and the repository features code that was either linked by the contributor or, in some cases, re-constructed as a New Project by the editor for convenience. And not all programs used in the book or online appear here, because some of the examples are only program fragments taken from other programs that cannot be included, and some code is drawn from existing projects hosted elsewhere. So the mapping between a recipe in the book and a directory here is approximate, and the mapping between a directory here and a complete application is also approximate. Anyone planning to use this as a reference should read the project table rather than assume that a recipe title corresponds to a buildable project.

One directory per project, and how the project table is generated

Each directory contains one project, and if the project is used in the book the directory name is cited at the end of the corresponding recipe under the Source Code Download section. The list of projects is generated periodically from the project folders, and the table has columns for the project, the author, the function and the notes. The author column is described as recently added, with an invitation to report mis-attributions, and the generated table is assembled by a script rather than by hand. The Makefile at the root shows the mechanism, since the default target takes the README, cuts it at a marker comment, runs a list-generating script, and appends the closing table syntax, with a comment explaining that the marker exists because GitHub does not allow include directives in files. The table entries carry real information in the notes column, such as a warning that one project works under Maven while Eclipse fails with a Maven configuration problem.

The Eclipse story: AndMore lost its contributors and Studio took over

The most interesting part of the README is the account of a support project that failed. Some older projects started in Eclipse also carry configuration files so they can be opened in Android Studio. During the runup to the second edition of the book, AndMore appeared to be a viable project to maintain Android Eclipse development, but it has become clear that AndMore has not attracted enough developer talent to remain viable, so the newest projects here are Android Studio only. The README also records that issue number 1 calls for moving the existing mass of projects to Studio only format. This is a rare and honest artefact, a record of a project deciding to stop supporting a tool rather than drifting. The consequence for a user today is that the collection is a mixture of two build systems, and the newer half is the more convenient one.

Gradle and the Android plugin are never current, and Studio fixes it for you

The README has a note that explains how the staleness works in practice, and it is a helpful one. Since Gradle and the Gradle Android plugin need to be updated just about every time you run Android Studio, there is no attempt made to keep things up to date here, and the advice is to let Studio do its upgrade thing for you. Except for really old projects, where you would have to upgrade six or eight times, and for those the recommendation is to copy newer build.gradle files from a sibling AndroidTemplate directory, or to read the maintainer's blog post on modernising Android. So the intended workflow is not to keep the repository current but to let the local toolchain rewrite the build files on first open. That is a reasonable division of labour, and it is also why the collection still works at all.

What the project table shows about the coverage

The visible entries in the table span a wide range of Android topics, and reading them is a good way to understand what an Android developer needed recipes for over the book's lifetime. There is a re-usable About dialog, device and screen information, an ActionBar demo, adding a contact which shows ContactsContract and a content provider, an AdMob demo with interstitial ads, a Google Analytics demo, a graphing project, an RSS reader, installing another app for downloading and package management, App Shortcuts appearing on long press of the launcher icon, the Application Singleton pattern, an AsyncTask demo, a contact picker with autocomplete, an app that can update itself, the Android Backup scheme, Bluetooth connection to a device, boot receiver, bookmarks, a calendar adder, call interception in both directions, the camera intent, cards, checkboxes and radio buttons, a custom ViewGroup, content providers, a Cordova demo, a countdown timer, crypto demos, a widget, cursor loaders, custom menus, a custom Toast, a database from a file, date formatting, smali demonstration, dialogs, drag and drop, dreams, email with attachments, an epoch JavaScript calendar, event listeners, a face finder, the Facebook SDK, file locations, the FileProvider, filesystem demos, a floating action button with a snackbar and a Flutter demo. The range tells you the era and the priorities.

The canonical project layout, spelled out in the README

The README includes a directory tree for what a canonical project looks like, which is one of the more immediately useful things in it for anyone starting a new Android project. At the top there is a README.txt and an app/ directory holding app.iml, a build/ directory, build.gradle, a libs directory, proguard-rules.pro and the src tree. The src tree has androidTest and test source sets alongside main, and under main there is the AndroidManifest.xml, the java source under a package path, and a res directory with drawable, layout, mipmap and values subdirectories, where values holds colors.xml, strings.xml and styles.xml. At the project root there is build.gradle, the gradlew and gradlew.bat wrappers, local.properties and settings.gradle. Nothing here is modern in the sense of version catalogues or Kotlin DSL, and that is exactly the point, because it is what an Android project looked like at the time the recipes were written.

Maintenance state and what has been split out

The last push to the repository was on 2026-07-02, the repository is not archived, and there are no GitHub releases, which fits a collection of example projects rather than a library. The README also records that some projects have graduated out of the collection, which keeps the archive from becoming a dumping ground. The JpsTrack and ToDo applications have graduated to their own GitHub projects under the maintainer's account, the Hello*Test projects are moving to names starting with Testing, and DuellingIDEs has been removed since the duel is over, with the advice to just use Android Studio. That last removal is a small joke and an honest summary of the whole project, and the pattern of the collection, some samples promoted, some renamed, some deleted, is what a well-kept archive of its kind looks like.

Editorial conclusion

The repository suits a developer who wants to see how a specific Android API was actually used, or who needs a compilable reference for a recipe pattern, and who is prepared to let Android Studio upgrade the build files on first open. It is the wrong tool as a source of current best practice, because the README states plainly that a lot of the code is out of date and that there is no attempt to keep it up to date. Before adopting anything from it, read the README note about Gradle needing to be updated nearly every time Studio is run, and check the project table for the author and build tooling, because a recipe from the first edition of the book may target an API that has since been deprecated.

Frequently asked questions

Official sources

1. IanDarwin/Android-Cookbook-Examples on GitHub
2. Issues
3. Project website
4. README