A lost connection should not always mean lost work. Offline behaviour can help a person complete a task in an unreliable network—or keep records on their own device when that fits the product’s purpose.
Start with the task that must continue
“Works offline” is too broad to be a useful requirement. Identify the specific actions that must remain available: starting a record, editing a note, viewing a saved schedule or exporting information. Decide what can wait until a connection returns.
The interface should make those boundaries understandable. A person needs to know whether an action has been saved locally, sent to another system or still requires attention. Avoid making them guess from a spinner.
Decide where the data belongs
Local storage changes the ownership and recovery questions. Is there a backup? What happens when a device is lost or replaced? Can the person export the data, and in a format they can use elsewhere? Which copies remain after the app is removed?
These decisions should match the product’s actual behaviour and privacy notice. “Offline” does not automatically mean that every feature avoids the network. External maps, geocoding, support messages or user-chosen exports can create separate data flows.
Plan what happens after a conflict
If records later synchronize with a server, two devices may have edited the same information. The product needs a rule for deciding which version is accepted and a clear way to recover from an unexpected result.
Duplicates, delays and interrupted transfers deserve attention too. A repeated tap should not silently create repeated financial or operational actions. The exact solution depends on the product’s data model and the systems involved.
Explain permission choices
A location feature should serve a specific action and behave predictably when permission is declined. A notification should help the person understand an ongoing activity. Users should understand what a choice changes without needing to understand Android internals.
Include the permission-declined journey in the design. If an action remains possible manually, make that route easy to find. If the feature cannot work, explain the limitation at the relevant moment.
Verify the transitions
Check more than a launch with the network switched off. Review the task when connectivity disappears mid-action, returns after a delay or changes while the application is no longer visible. Consider app restarts, interrupted exports and a user correcting an earlier record.
The checks should follow the essential journey and its risks. A successful build is useful evidence about compilation; device behaviour needs its own evidence.