App permissions
Seven declared, one removed, each with what refusing it costs you.
This page covers the Android build. Everything on it can be checked against the app's manifest, and clause 02 explains why four separate documents have to agree before a build is allowed out.
The complete list#
| Permission | What it is for | If you refuse |
|---|---|---|
| INTERNET | Reaching the service. There is no offline-only mode for a system whose whole job is shared records. | Cannot be refused. It is granted at install and is not a prompt. |
| ACCESS_NETWORK_STATE | Knowing whether you are online, so a collection recorded in a basement queues instead of failing. | Cannot be refused, and it reads a status rather than any content. |
| POST_NOTIFICATIONS | Telling you a critical result needs acknowledging, or a run has finished. | Everything still works. You check the app instead of being told. |
| CAMERA | Scanning a barcode on a tube or a request form at the bench and at the bedside. | Type the accession number instead. Slower, and it still works. |
| ACCESS_FINE_LOCATION | Home collection and phlebotomy rounds: which visits are near you, in what order. | The round is assigned and ordered manually. Nothing else changes. |
| ACCESS_COARSE_LOCATION | The same, at lower precision, for devices or users that prefer it. | As above. |
| AD_ID | The advertising identifier. Declared and kept, for measurement now and for advertising when advertising arrives. Clause 05 is the whole of it. | Android lets you reset it or switch it off in your device settings, and the app carries on. Nothing clinical is keyed to it. |
| RECORD_AUDIO | Removed from the merged manifest on purpose. A dependency declares it; LabFlow records no audio. | Never requested, so there is nothing to refuse. |
There is no background location, no contacts, no call log, no reading or sending of text messages, no microphone and no all-files access. Clause 07 lists what is deliberately absent.
Four documents have to agree#
A permission is only allowed into a release when it says the same thing in four places: the merged Android manifest, this page, the privacy policy, and the store's data-safety declaration. Any one of the four disagreeing stops the release.
The reason is specific rather than principled. Plugins inject permissions into the merged manifest that nobody wrote into the source, so what an app actually asks for is routinely different from what its developer believes it asks for, and the first person to notice is a reviewer. Checking the merged manifest rather than the source is the only version of this check that works.
Camera#
Asked for the first time you scan something, not at startup, and with the reason on screen at that moment. The camera is used to read a barcode. Images captured for a record, such as a photograph of a requisition, go to file storage and are held under the same rules as any other content in the tenant.
The scanner never uploads a frame it did not need. There is no continuous capture and no background use.
Location, and the three things it is not#
Location is used for home collection and phlebotomy rounds, so that a route can be ordered sensibly and a visit can be recorded as having happened where it was supposed to.
- Not in the background. The background location permission is not declared, so the app cannot read your position when it is not open. Refusing to declare it is what makes that a fact rather than a promise.
- Not continuous. Position is read when you act, not on a timer.
- Not for advertising, and not shared. It reaches the tenant's own visit record and nowhere else.
The advertising identifier, declared and kept#
The Android manifest declares the advertising identifier permission, and it stays declared. It is there by decision rather than by accident: LabFlow expects to carry advertising, and the advertising identifier is the thing an advertising or attribution service reads. Declaring it up front is what keeps this page, the app's manifest and the store's data-safety declaration saying the same thing on the day one is switched on, instead of two of the three being updated and the third quietly contradicting them.
No advertising network and no attribution service is in the app today, so nothing reads it today. That is a description of this build rather than a promise about every build. A flat never is the sentence that quietly becomes false, which is the same reasoning clause 05 of the privacy policy gives about measurement — so this clause is written as a commitment instead: when something does read the identifier, it appears in the table in clause 01, in the privacy policy and in the store listing before it is switched on, and the change appears in the feed.
Android treats this as a resettable identifier rather than a permanent one. You can reset it, or opt out of it entirely, in your device's own settings at any time; the app keeps working either way.
Text messages need no permission, and carry no clinical content#
The app can nudge a patient or a colleague by text. It does this by opening your own messaging app with the message prefilled; you read it and you press send. That path needs no permission at all, which is why it was chosen over sending directly.
On the web there is no text message feature at all.
The browser build#
In a browser there are no Android permissions, only the prompts your browser shows: camera for scanning, location for rounds, and notifications. Each is asked at the moment the feature is used and each can be refused with the same consequences as the table in clause 01.
The site also sends a permissions policy header restricting camera, microphone, location and payment to this origin, so an embedded frame cannot use them. Microphone and payment are listed in that header while neither feature exists, which is a leftover rather than a plan, and it is narrowed in the rebuild.
Where the app actually is#
The Android app has never been published to any store. It exists, it builds, and it has been used only by the LabFlow team. Nobody has installed it from a store listing, because there is no store listing.
That is worth stating on the page that explains its permissions, because a permissions page usually implies a published app, and an implication is the easiest kind of false claim to make by accident.