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.
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 approved 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.
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.