- Platform Versions
- Development Tools
- User Interface
- Coding Conventions
- Best Practices
- .gitignore
- Test-Driven Development
- Preferred Libraries And Frameworks
- Location
- Dependency Management
- Project Environments
- Release Key
- Graphic Assets
- ProGuard
- Useful Links
Support Android OS versions starting from 5.0 (Lollipop, API Level 21). Do not support older versions (2.2 Froyo, 2.3 Gingerbread, 3.x Honeycomb, 4.0.3 - 4.0.4 Ice Cream Sandwich etc). Check Dashboard page for information about platform versions, screen sizes and densities statistics.
For new projects, use latest stable version: Android 11 (API level 30). Do not use beta versions or developer previews.
Use Java Development Kit (JDK) version 8.
Use latest stable Android Studio.
Follow MLSDev Android Coding Conventions.
Use Android Studio for auto formatting.
- Prefer Kotlin to Java for new projects
- Avoid anonymous classes usage
- Use ContentProviders
- Prefer Services for long-running background tasks
- Understand Coroutines and LiveData usage.
- Use Analyse->Inspect Code in Android Studio for static analysis of project code and XML at the end of each development cycle (Iteration, Spring, Milestone etc)
- Use MVVM architecture
Follow Android Design Principles, particularly the Style Guide.
Useful links:
Use IDE for default .gitignore file generation.
Do not forget about OS temporary files (.DS_Store in Mac OS, Thumbs.db in Windows etc).
- Use Android JUnit for unit tests.
- Use Mockito for mocks.
- Use Espresso for automated UI tests.
- Use Spoon for testing on multiple devices
- Use latest stable Retrofit to access RESTful web services
- OkHttp for more flexible networking (for example, when the API is not RESTful)
- GSON or Moshi for JSON serialization and parsing
- Glide or Picasso for image downloading, caching and displaying
- Firebase Crashlytics for crash logs
- Dagger 2 or Koin for Dependency Injection
- Kotlin Coroutines for asynchronous programming
- POJO JSON classes generator.
- Java code coverage library by EclEmma - JaCoCo
- Android data binding
- Flipper, Stetho debug tools
- Kotlin plugins Ktlint, Detekt
Prefer Google Play Services to LocationManager
Never add third-party source code or libraries to project repository. Use Gradle and Maven.
Project should contains at least 2 Gradle tasks: Release and Debug.
Release task should include:
- release build signing (see Release Key section)
- positive Crashlytics flag
- configuration for the stable API version
Debug task should include:
- debug build signing
- negative Crashlytics flag
- configuration for the development (staging) API version
- Release key file can be stored in project tracker (JIRA, Redmine etc), password can be on Wiki page or some other private/secured place.
- Generating Release key. Main information needed from client - company name and location.
- Info on Jenkins setup
- Require graphic designers to provide assets in all sizes (mdpi, hdpi, xhdpi, xxhdpi etc).
- Prefer 9patch graphics.
- Prefer Multi-Density Vector Graphics.
More info: MLSDev Design Requirements
- Use Proguard tool for improving security of your application. Proguard obfuscates your code by renaming classes, fields, and methods with semantically distorted names. The result apk file is more difficult to reverse engineer. It's important to use Proguard when your application should hide authorization protocol (e.g. client_id and client_secret of OAuth).
- Proguard tool shrinks and optimize your code which can help you remain within 65k methods.
When working with legacy code it's important to know is ProGuard enabled or not. While you are making changes you should add appropriate rules into configuration file.
Whenever ProGuard runs, it outputs a mapping.txt file, which shows you the original class, method, and field names mapped to their obfuscated names. You must keep mapping.txt file for every release build, otherwise you will be unable to read stack trace of crash reports.
- Android Weekly - subscribe to it!
- Kotlin Weekly - subscribe to it!