android-best-practices

This is a written guide rather than a piece of software. The consultancy Futurice collected the dos and don'ts their Android developers had learned over many projects and published them as a single best-practices document so other teams can avoid reinventing the wheel.

The README is organised as a long checklist with deeper explanations underneath each item. It opens with build advice, such as using Gradle and its default project structure, keeping passwords and keystore details out of build.gradle and in gradle.properties instead so they never reach version control, and preferring Maven-resolved dependencies over committed jar files with fixed static versions. It also warns against dynamic version ranges like 2.1.+ because they can produce unstable builds.

It then moves through library choices, recommending Jackson for parsing JSON and OkHttp for HTTP rather than rolling your own client, and warning that pulling in heavy libraries such as Guava can push you over the 65,000-method limit that the platform imposes on a single dex file. Architecture sections cover when to lean on activities versus fragments, how to treat layout XML files as real code with shared styles, short colors.xml and dimens.xml palettes, and shallow view hierarchies. There is also a note on being careful with WebViews and avoiding leaks.

The later sections cover testing with JUnit, Espresso, and AssertJ-Android, debugging with Stetho, finding memory leaks with Leak Canary, shrinking and obfuscating with ProGuard or DexGuard, picking SharedPreferences or ContentProviders for persistence, and running continuous integration. A developer would reach for this when starting a new Android project or auditing an existing one to spot patterns that tend to cause trouble later. Futurice publishes parallel guides for iOS and Windows app development.