Verify EXIF and XMP Policies on Android Image Export Copies

Direct answer

Treat metadata as an export-copy contract, not a privacy switch. Decide which fields to preserve or remove and what is out of scope. EXIF can hold GPS, capture time, camera/software identity, orientation, and thumbnails; XMP is a separate metadata model that may be stored in another part of the file. Removing GPS tags does not remove location visible in pixels. The AndroidX ExifInterface 1.4.2 API reads JPEG, PNG, WebP, HEIC and RAW formats, plus AVIF on Android API 31 or newer, but saveAttributes writes only JPEG, PNG, and WebP. MIME/read support is not writer support. Pin the library and output format; unsupported output must fail without a share artifact or use an explicitly tested decode/re-encode path. Never mutate the user's source. saveAttributes rewrites its input through a temporary copy, deletion, and rename. Create an app-owned copy first, update that copy, write to a separate temporary destination if needed, reopen and verify the result, then offer export. On any error keep the original intact and do not expose partial bytes. ExifInterface.setAttribute(tag, null) removes a selected tag in its attribute state; setGpsInfo(null) is a no-op, not a GPS wipe. Inventory coordinate values and reference tags plus the location fields in scope, then reread the saved copy to check them. Preserve Orientation or normalize the pixels before removal; otherwise a recipient may display unchanged pixels differently. EXIF edits do not guarantee XMP removal. AndroidX documents that XMP can live inside EXIF or in a separate format-specific location. If a JPEG has XMP in both places, ExifInterface reads and writes the EXIF-contained packet while leaving the separate packet unchanged. Release notes also record version-specific XMP fixes. Checking only GPSLatitude after save therefore cannot establish that every packet is clear; treat unsupported packet paths as unknown. Verify independently by opening the final file with a fresh parser. Check the selected tags, supported XMP locations, thumbnail, orientation, and encoded format. Use fixtures with fake GPS, time, device tags, orientation, thumbnail, and dual XMP locations; assert both required removals and fields that must remain. Malformed or unsupported metadata should fail or remain unknown, not pass as clean. Limit the claim to the tested file and fields. GPS-tag removal does not erase coordinates in visible pixels, filenames, sidecars, previews, logs, backups, or copies sent to another app. CIPA Exif and XMP standards describe metadata fields and storage; they do not prove one library call scrubs every container. Preview the exact export, require a user action, and never call a selectively cleaned image anonymous. This is a general Android export method, not a claim that Cove strips photo metadata. Cove's OCR fact documents visible-text output and copy/history actions, not processed-photo export. Before implementation, identify the actual source, destination format, ExifInterface version, XMP handling, and recipient handoff. Keep source preservation, metadata editing, re-encoding, and sharing as separate steps.

An edited photo is ready to share, but its metadata policy is unclear

An Android app creates a cropped copy from a user-selected photograph. The team wants to remove GPS coordinates from the exported copy but preserve display orientation. The source can contain EXIF data and a separate XMP packet, and the chosen output format may not support the same metadata writer operations.

Decision

Keep the source immutable, define an explicit output tag policy, mutate only a supported app-owned copy, and verify the completed bytes with a fresh parser before presenting the user-directed export.

Expected outcome

The exported artifact has test evidence for the selected fields and format, while unexamined XMP, thumbnails, filenames, and visible image content remain outside any anonymity claim.

Evidence to collect

The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:

• Pinned writer support and selected tag policy
• Dual XMP, GPS, orientation and thumbnail fixtures
• Fresh output verification and immutable source bytes

A privacy claim needs a data inventory and traffic evidence. A local-model label by itself is not proof.

Implementation workflow

1. Inventory source, destination, and policy. Record the input container, source URI/file ownership, candidate output format, recipient, and selected preserve/remove fields. Include GPS coordinates/references, time, device/software tags, orientation, thumbnails, and XMP as separate checks instead of a vague remove-metadata switch.
2. Pin the writer contract. Record the exact AndroidX ExifInterface version and output MIME type. Its documented write set is narrower than its read set; use saveAttributes only for supported formats. Treat isSupportedMimeType as a read-format check, not proof that the output writer can save the format.
3. Create an app-owned copy before mutation. Never call saveAttributes on the original user source. Write to a new private working copy, preserve the original until success, and use an additional temporary output plus a verified promotion step if failure-safe export requires it.
4. Apply exact tag operations. Clear selected tags individually with the documented nullable API and keep orientation only if the encoded pixel matrix still needs it. Do not use setGpsInfo(null) as a deletion operation; the API documents null as a no-op. Handle EXIF-contained and separate XMP according to the pinned library behavior.
5. Reopen and verify the final artifact. Use a fresh ExifInterface or format-aware verifier after writing. Check target format, selected GPS tags, time/device tags, orientation, thumbnail, and XMP locations covered by the policy; mark unhandled segments unknown rather than clean.
6. Expose a bounded export claim. Preview the exact output and require an explicit user action. Explain which tested fields were removed from which format, and keep filenames, sidecars, visible content, logs, prior copies, and recipient retention outside a complete-anonymization claim.

Keep each transition observable. A failure should identify the stage, artifact, runtime, and recovery action without logging private user content.

Acceptance criteria

• The original source bytes remain unchanged on both success and every injected parse/write/verification failure; metadata mutation only targets an app-owned export copy.
• The writer library version and output format are pinned, and its documented write support is distinguished from read support and MIME detection.
• Tests verify each selected GPS/time/device removal and each required orientation/thumbnail-preservation behavior by reopening the final file; EXIF and separate XMP locations are tested separately where supported.
• User-facing copy describes only verified fields and output format; it does not equate selected EXIF removal with complete metadata deletion, anonymity, removal of visible location clues, or recipient-side erasure.

Decision table

Failure patterns to prevent

• Mutating the user source with saveAttributes
• Treating setGpsInfo null as deletion
• Equating selected GPS removal with anonymity

Also prevent silent fallback, unpinned artifacts, missing cancellation, and conclusions that combine unlike configurations. Store unsuccessful runs alongside successful ones.

Minimum reproducibility record

Release checklist

• ☐ The primary query is answered without an unsupported number.
• ☐ Every artifact and runtime is pinned.
• ☐ The representative task and failure policy are explicit.
• ☐ Lifecycle, cancellation, cleanup, and fallback are tested.
• ☐ User-content and network boundaries are documented.
• ☐ Result wording applies only to the recorded configuration.
• ☐ The page links to raw method or evidence when results are added.

Sources and related evidence

• Android privacy and security
• AndroidX ExifInterface API: format support, tags, XMP, and saveAttributes
• AndroidX ExifInterface release notes: version-specific XMP fixes
• CIPA Exif standards: Exif 3.1 and Exif metadata for XMP
• Adobe XMP specifications: metadata storage and reconciliation

Chinese deployment and troubleshooting content is organized in the .奇连 AI 端侧专题.

Frequently asked questions