Website | Docs | Jetpack | Testing | Security | Performance
App fundamentals: Four different types of app components (activities, services, broadcast receivers, content providers), three of which activated by intents. Application components declared in an application manifest. Apps also contain resources.
App resources: Overview discusses the different kinds of resources, the use of project file structure (
res/ directory and subdirectories) to group them, and the convention-based approach to providing alternative resources depending on the device hardware. Accessing resources via code or referencing them from the various XML files. If access to the original files is necessary, store them as "assets" (in
assets/) instead of as "resources". Describes how Android finds the best resource match. Handle configuration changes describes how Android handles device/hardware configuration changes (such as screen orientation) by either retaining an object (in which state is stored) or by handling the configuration change manually. Localize your app is the first guide in the Localization section (Test your app with pseudolocales, Unicode and internationalization support, and Language and local resolution are the rest); in essence, it's more about resource management again. Complex XML resources describes a means by which multiple related XML resources can be collected into one file via AAPT. Resource types lists out the different resource types available in Android: Animation, Color state list for changes based on View state, Drawable resources like graphics, Layout resources for UI, Menus, Strings, Styles, Fonts, and more (booleans, colors, dimensions, IDs, integers, int arrays, and typed arrays).
App manifest, which includes links as a reference to each of the XML elements in the manifest file format.
App architecture: Kicks off the Android app architecture section:
- A guide to app architecture, which is broken out into the UI layer and events, the domain layer, and the data layer.
- A collection of architectural components:
UI layer libraries:
- View binding for binding controls to object references inside the Activity, based on doing some codegen during compilation.
- Data binding binds UI components directly to data sources. Get started, use layouts and binding expressions to write expressions that connect variables to the views in the layout, work with observable data objects, use and customize generated binding classes, work with binding adapters, bind layout views to architectural components, and/or use two-way data binding.
- Lifecycle-aware components: Handle lifecycles more easily through components, build ViewModel classes designed to store and manage UI-related data in a lifecycle conscious way such as to allow data to survive configuration changes such as screen rotations, use LiveData (an observable data holder class) which is lifecycle-aware (meaning it respects the lifecycle of other app components, ensuring LiveData only updates app component observers that are in an active lifecycle state), save state discusses preserving and restoring state during the lifecycle (which also has some discussion around ViewModel state preservation); Kotlin coroutines play a part here too (though I'm not 100% sure why or how just yet).
- Paging (v3) library describes how to load and display pages of data from a larger dataset from local storage or over network. There's also an older (v2) library that seems deprecated.
- Slices: UI templates that can display rich, dynamic, and interactive content from your app from within the Google Search app and also in other places like the Google Assistant. Slices can help users perform tasks faster by enabling engagement outside of the fullscreen app experience. Getting Started and Slice templates.
Data layer libraries:
- (Jetpack) DataStore: a data storage solution that allows you to store key-value pairs or typed objects with protocol buffers. DataStore uses Kotlin coroutines and Flow to store data asynchronously, consistently, and transactionally. If you're currently using SharedPreferences to store data, consider migrating to DataStore instead.
- (Jetpack) WorkManager: an API that makes it easy to schedule reliable, asynchronous tasks that are expected to run even if the app exits or the device restarts. The WorkManager API is a suitable and recommended replacement for all previous Android background scheduling APIs, including FirebaseJobDispatcher, GcmNetworkManager, and Job Scheduler.
App actions: Voice-enabled actions on an Android device.
On-device search enables the device to search documents stored in the search database, even when offline.
Handle mixed connectivity: Store data, queue requests, handle images properly for offline/slow connections.
Build for device range: Lower app memory footprint, build for a range of device capabilities
Provide data controls: Give users control over app's data, reduce app's size, be mindful of consumption
Use battery efficiently
Privacy: Pay attention to permissions; minimize use of location; handle data safely; use resettable identifiers
Accessibility: Make apps more accessible, Principles for improve app accessibility, Testing app accessibility, Making custom views more accessible, Creating custom accessibility service
Links, Libraries, etc
Simplify: Generic Android Deobfuscator: "Simplify virtually executes an app to understand its behavior and then tries to optimize the code so that it behaves identically but is easier for a human to understand. Each optimization type is simple and generic, so it doesn't matter what the specific type of obfuscation is used."
Last modified 06 April 2022