Direct answer

Design a safe Android NFC write flow with payload validation, capacity checks, verify-after-write, TagLost recovery, locking safeguards and clear states.

Start with a complete payload, not a waiting tag

The user should choose the record type, enter content and pass validation before NFCMagic arms the radio workflow. Asking for a tag too early increases accidental reads, unclear timeouts and writes made with stale form values.

Immutable attempt
Freeze the encoded payload for one armed attempt so UI edits cannot change the bytes halfway through a physical interaction.
Visible summary
Show record types, destination host and encoded size immediately before the user presents the target.

Preflight the target tag

After discovery, inspect Ndef or NdefFormatable support, current message, writable state and maximum NDEF size. A visually blank sticker may already be locked, partly formatted or built on a technology that needs another operation path.

Compatibility gate
Do not offer an NDEF write when Android exposes neither a writable Ndef container nor a supported formatting path.
State-specific error
Report unsupported, read-only, insufficient capacity and connection loss separately because each requires a different user action.

Calculate the final encoded size

Capacity must be checked against NdefMessage.toByteArray rather than visible character count. URI compression, UTF encoding, language codes, MIME types and record headers make two similarly sized text fields produce different stored lengths.

Target evidence
Compare the exact byte array with maxSize reported by the connected tag instead of relying only on a chip model selected in advance.
Useful guidance
When content is too large, identify which record dominates and suggest a shorter controlled URL rather than displaying a generic failure.

Use an explicit write state machine

A reliable sequence is Draft, Ready, Armed, TagDetected, Writing, Verifying and Completed or Failed. Each transition owns its controls so a second tap cannot start a competing write while the first I/O call is still active.

Single operation
Disable destructive and navigation controls during Writing and close the active technology when the attempt finishes.
Session identity
Attach a unique attempt identifier so delayed callbacks cannot overwrite the result of a newer scan.

Handle field loss and interrupted writes

A passive tag loses power when it leaves the usable field. Android may surface TagLostException or IOException, but the physical memory can be unchanged, partly changed or valid depending on the chip and the moment of interruption.

Honest failure
Do not label every exception as definitely unchanged; instruct the user to hold still and scan the target again before retrying.
No blind loop
Automatic repeated writes can amplify uncertainty. Return to a deliberate verification or retry state after reconnecting.

Verify after every important write

A successful write call confirms the API operation, while a re-read checks the actual NDEF message now presented by the tag. Compare bytes or canonical record values and show verification as a separate result.

Comparison rule
Normalize only fields whose representation is intentionally equivalent; otherwise compare the serialized message to catch missing or reordered records.
Batch evidence
Store write success and verification success independently so production reports do not count an unverified target as finished.

Treat read-only conversion as permanent

Android's Ndef.makeReadOnly can set capability and lock data that cannot be reversed. It should never be a default post-write step or share a vague confirmation with an ordinary write.

Two-stage consent
Show the exact target, explain that future edits may become impossible and request a fresh confirmation immediately before the lock attempt.
Post-lock proof
Reconnect and report the observed writable state; also record when a platform or tag cannot guarantee permanent locking.

Distinguish password protection from cryptographic security

Some NTAG21x products offer a 32-bit password and PACK for access control, but this is not a substitute for a secure authentication IC and backend verification. The feature is manufacturer-specific and requires careful page configuration.

Scope
Use password controls to reduce casual unauthorized writes on compatible tags, not to claim protection equivalent to AES mutual authentication.
Secret handling
Do not log the password or PACK, and make removal or update flows verify that the presented target is the intended tag.

Design clear success and error feedback

The result should combine text, icon, color and haptic feedback. A single green flash is not enough for a user holding a phone over a label in bright light, nor is an unexplained error code useful to an operator.

Success detail
Show what was written, whether verification passed and whether the tag remains writable.
Recovery detail
For capacity, protection and movement errors, provide one concrete next action instead of restarting the entire composer.

Build a release and field checklist

Writing must be exercised on real tags across payload sizes, reused memory states and device antennas. The test matrix should include deliberate movement, a full tag, a locked tag and an incompatible technology.

Regression set
Keep known test tags for empty, near-capacity, read-only, password-protected and malformed cases, clearly labelled to prevent accidental reuse.
Operator procedure
Document where to hold each phone model and when it is safe to remove the tag, especially in a batch station.

Quick reference

State Required evidence Unsafe shortcut
Ready Validated encoded payload Arming from an incomplete form
Detected Writable technology and capacity Assuming every blank label is writable
Written API operation returned successfully Calling this verified
Verified Re-read matches intended NDEF Skipping physical confirmation

Related NFCMagic app screens

These screenshots connect this safe NFC write flow guide to the related Android workflow in NFCMagic. They document interface states; radio behavior still requires a physical Android device and real tags.

NFCMagic Android Write composer with validated NDEF payload and serial write state
The target is requested only after the payload is valid and the user has intentionally armed writing.
NFCMagic NFC Tools screen for copy, format, erase, password and read-only operations
Irreversible and manufacturer-specific operations are separated from ordinary composition and writing.

Frequently asked questions

Why should an NFC write be re-read?

A re-read confirms the physical tag now exposes the intended NDEF message rather than relying only on the return value of the write call.

Can a failed write leave partial data?

It can, depending on the tag and when power was lost. Scan the target again before deciding whether to retry.

Can a read-only NFC tag be unlocked?

A permanent read-only operation is designed to be irreversible. The app must explain this before attempting it.

Is an NTAG password equivalent to AES authentication?

No. A short manufacturer password controls compatible memory operations but does not provide the same security model as a secure cryptographic IC.

Primary technical sources

  1. Android Developers: Ndef API — API contract for capacity, writability, NDEF I/O and permanent read-only operations.
  2. Android Developers: Advanced NFC — Official guidance for tag technologies, NDEF operations and foreground dispatch.
  3. NXP: NTAG 213, 215 and 216 — Official capacities, RF characteristics, lock features and target applications.