A sharp photo can still be wrong evidence when it is attached to the neighbouring asset's work order. The application must preserve the intended record context through camera hand-off, local storage, an offline queue, upload and backend acknowledgement. A filename, timestamp or GPS coordinate may help an investigation, but none of them alone proves which inspection item the operator meant to document.
This guide is for field-service teams, inspection programme owners, mobile-app integrators and rugged-tablet buyers. The scenario is editorial, not an AIDC GO customer deployment or camera test. Review the rugged-tablet category, Field Service and Inspection, rugged-tablet field operations, Integration Support and Contact only after the application record model is defined.
Bind the capture intent to an immutable record context
Before opening a camera, display and retain the work-order ID, asset ID, inspection-item ID and attachment purpose. The user should be able to see which record will receive the next image. If the operator changes assets while the camera is open, the application must either keep the original capture context or cancel and require a new capture; it must not silently attach the result to whatever record happens to be visible afterward.
Android's current Camera intents documentation, updated July 2026, describes delegating basic capture to another application through an Intent and handling the result when focus returns. It also notes that an application can use CameraX or Camera2 for more complex integration. This supports an implementation boundary: returning from a camera is an application event, not proof that a business attachment was saved to the right record.
Store a stable local attachment identity alongside the original business context. A useful record can contain local_attachment_id, work order, asset, inspection item, file URI, capture state, content hash where appropriate, upload attempt identity and server attachment ID. Do not rely on the filename alone; camera applications and users can rename, duplicate or replace files.
Decide whether the thermal attachment must remain measurable
If an inspection includes thermal imaging, decide whether the deliverable is a visual record or a file that a reviewer must analyse for temperature after capture. These are different requirements for the camera output and software path, not automatically two different tablet models. A colour image or a displayed temperature does not establish what data the saved attachment retains. A project that only needs a visual record should not be assigned a radiometric-analysis package without a task requirement.
As a named example, the FLIR Exx series manual, T810587 revision AH, describes a radiometric JPEG containing thermal information as well as a regular JPEG component for convenient viewing. It also says that saving in Digital camera image mode stores no thermal information. Those are that camera family’s documented behaviours, not properties of every JPEG or AIDC GO camera. FLIR’s Lepton radiometry guide likewise distinguishes temperature-data output from contrast-enhanced imagery for its specified compatible modules; measurement depends on the system and the stated scene parameters.
Compare quotations against the required delivered result: the specified camera or module, capture mode, supported application and any analysis software needed to reopen that result. Include the work to retain and transfer the required data, rather than treating a preview or screenshot as proof. In an illustrative inspection, one offer supplies a viewable image attached to an asset; another preserves a documented radiometric file for later analysis. They are not equivalent if the reviewer must inspect temperature data, but the additional path is unnecessary if the accepted task only needs the picture. Neither example establishes AIDC GO thermal-camera supply, software licensing, compatibility or a measurement result.
Keep the required original file linked to the same work order, asset and inspection item as its preview. Have the application team demonstrate reopening the accepted attachment in the supported analysis tool after the actual save, export and upload path; a correctly linked but unusable derivative does not complete that requirement. This supplements the association checks below rather than replacing them. It does not establish measurement accuracy, a diagnostic conclusion or a safety decision.
Distinguish five photo states
Design the screen and audit trail around observable states rather than one ambiguous check mark.
| State | Evidence to keep | What remains unproven |
|---|---|---|
| Capture requested | Work order, asset, inspection item and intended attachment type | No photo has necessarily been created. |
| Saved locally | Stable local ID, file URI, size/readability and bound record context | The backend has not necessarily received it. |
| Queued | Upload operation ID, target record and retry policy | The queue has not necessarily run successfully. |
| Uploaded | Transport response and server attachment ID | The attachment may still need application-level validation. |
| Accepted on record | Readback under the intended work order and inspection item | The image alone does not prove the physical condition or authenticity. |
The field-inspection guide keeps asset IDs, forms and photos together across an inspection. This article examines the narrower attachment lifecycle when several records are handled in sequence.
Follow two neighbouring assets through one editorial route
Assume a technician must inspect pumps P-204 and P-205 under work orders WO-771 and WO-772. Each work order has an inspection item called nameplate condition. These values and all results are constructed for explanation.
The technician opens WO-771 / P-204 / nameplate condition. The application creates local attachment identity ATT-L-901, freezes that record context, and launches capture. When the image returns, it shows a preview next to P-204, saves it locally and marks it queued—not uploaded. The technician then opens WO-772 / P-205. A second capture receives ATT-L-902 and the P-205 context. Similar-looking pumps do not allow the application to infer or swap the association.
Now introduce an interruption. The network disappears after ATT-L-901 is queued. ATT-L-902 uploads first when connectivity briefly returns. The application must not mark both attachments complete merely because one request succeeded. When the network stabilises, it retries ATT-L-901 with the same operation identity, receives server attachment SRV-5531, and reads it back beneath WO-771 / P-204 / nameplate condition. The technician can now distinguish local saved, queued, uploaded and accepted states.
If the preview reveals that the P-205 photo was taken while P-204 was selected, the correction is a deliberate re-association or delete-and-recapture action under project policy. Quietly editing the filename from P205.jpg to P204.jpg does not repair the business audit trail.
Make replacement and duplicate handling explicit
A supplemental photo, a replacement photo and a retry are different actions. A supplement creates another attachment with its own identity. A replacement should preserve which attachment it supersedes and why. A retry resubmits the same logical attachment and must not produce an extra backend row every time a timeout hides the first response.
The proof-of-delivery guide separates local capture, submission and accepted backend state for signatures. The same evidence discipline applies to photos, but the record key here includes work order, asset and inspection item.
For offline queues, Android's offline-first architecture guidance describes persistent queue draining as a use case often delegated to WorkManager, with retry and backoff. WorkManager is an implementation option for an Android application, not proof that a particular field application uses it or prevents duplicate attachments.
Verify software-specific offline behavior instead of assuming it
Microsoft Dynamics 365 Field Service is one bounded example of a field application. Its current offline data synchronization documentation describes offline-first synchronization, status, errors and conflict handling. Its mobile work guide says image notes can be linked to a booking. These facts belong to that product and its configured profiles; they do not establish an AIDC GO application feature or a universal Android attachment model.
The background-sync guide examines whether queued work continues when screen and process conditions change. This guide keeps a different invariant: whichever component performs the upload must retain the exact attachment-to-record relationship.
Test conflicts as well. If the office closes or reassigns a work order while a tablet is offline, the application needs an explicit rule for the pending attachment. A record not found, permission error or conflict response should not be converted into a generic upload success or attached to a replacement record merely because its asset name looks similar.
Do not treat metadata as the association proof
EXIF time, device time, coordinates and filename patterns can support troubleshooting, but each has limits. Device time can differ from server time; coordinates can be unavailable or too broad; filenames can be reused; metadata can be removed during processing. The authoritative association should be the application's recorded business key and backend readback under the intended record.
The timestamp guide distinguishes capture, sync and server receipt time. Keep those meanings separate instead of using the newest timestamp as proof that a photo belongs to the newest work order.
Privacy, retention and access rules also need project ownership. Decide who may view the image, which sites or people must not be photographed, how long local copies remain, and what happens after confirmed upload. This article does not supply legal policy. Do not clear local files during handover until the defined workflow proves that required attachments have been accepted or deliberately retained for recovery.
Accept the workflow with observable evidence
Build a test set with two adjacent assets, two work orders, repeated inspection-item names, offline capture, a network timeout after submission, a replacement image, a duplicate retry, an expired login and a record changed by the office. For each action, record the local attachment identity, target keys, visible state, operation identity, server result and readback location.
Inspect the proposed tablet in the real work posture: screen readability, focus, gloves, camera launch and return, preview detail, storage headroom, network transition, power and carry method. Camera resolution alone does not prove that operators can identify the intended asset or that the application retains context.
If the inspection also needs printed text converted into a business field, compare OCR and barcode capture, including the software quotation scope separately from saving a photo attachment.
Bring the work-order and asset identifiers, inspection schema, attachment API, offline profile, conflict rules, retry contract, privacy policy, sample image sizes and backend readback screen to the project review. Ask AIDC GO for model-specific Android, camera and integration documentation needed to test that exact application. The accepted result is not simply a JPEG on the device; it is an image read back under the correct inspection record with its lifecycle still auditable.
Devices for this workflow
