NFC Tag Programming on Android

Android NFC hardware landscape and compatibility considerations

Programming an NFC tag on Android is gloriously easy. Supporting NFC across every Android phone your customers actually own is the part that builds character. The platform rewards you with an unusually open NFC stack and then hands you a thousand slightly different phones to run it on — different antenna spots, different skins, different ideas about which settings menu NFC lives in. Unlike iPhone where NFC hardware and API capability advance lockstep across generations, Android devices vary significantly by manufacturer, model year and OS version. Understanding the landscape is the first step for any NFC programme targeting Android users at scale.

• NFC hardware prevalence: essentially all flagship Android phones from 2015 onward include NFC hardware (Samsung Galaxy S and Note series, Google Pixel all generations, OnePlus flagship and Nord series, Xiaomi flagship, Sony Xperia, Huawei Mate/P series pre-sanction, Motorola Edge). Budget Android phones are inconsistent. Some include NFC, some don't; customers in emerging markets frequently have NFC-less budget devices.
• Android OS version distribution. Android 4.0+ (Ice Cream Sandwich, 2011) introduced android.nfc; Android 5.0 (Lollipop, 2014) added Host-based Card Emulation (HCE); Android 10+ (2019) added Default Wallet app preferences; Android 13+ added refined NFC-reader mode APIs. Modern consumer programmes can safely target Android 9 (Pie) or Android 10 as baseline, covering 95%+ of active devices.
• Verifying NFC capability on a specific device. Settings > Connected Devices > Connection Preferences > NFC (exact path varies by OEM UI overlay). If NFC is listed and toggleable, the device supports NFC. Some manufacturers hide NFC in an "Other Settings" submenu; Samsung phones surface it in the Quick Settings panel.
• NFC antenna location variance. Unlike iPhone where the antenna is consistently at the top-center of the back, Android antenna locations vary by OEM. Samsung Galaxy phones typically have the antenna near the top-center; Pixel phones slightly lower; OnePlus varies by model. App prompts guide users to "hold the tag against the back of the phone" rather than specifying exact location; programmers of consumer experiences should plan for multi-location tapping attempts by users.
• Samsung vs. Google vs. other OEM NFC behavior. Samsung's OneUI adds some NFC-related customization (Wireless PowerShare overlap, Bixby routine integration, Samsung Pay priority). Google Pixel runs stock Android NFC behavior. Other OEMs (Xiaomi MIUI, OnePlus OxygenOS, Motorola) mostly mirror stock Android with minor UX variations. For developers, android.nfc API is consistent across OEMs; for content designers, consumer NFC interactions should work identically.
• Reader-mode iPhone interoperability. Modern Android NFC radios are fully backward-compatible with iPhone NDEF patterns. Consumer NFC programmes using NDEF URL records work identically on Android and iPhone, with background detection (Android: system NDEF URL dispatch to default browser; iPhone: system notification banner) behaving equivalently.
• NFC controller chipsets: most Android flagships use NXP PN544, PN548, PN80T, PN81A, or PN557 controllers; budget phones with NFC typically ship STMicroelectronics ST21NFCB or Samsung S3FWRN82. The controller choice is transparent to the android.nfc API but matters for edge-case diagnostics: PN557-family controllers are the most permissive for raw ISO 14443-3 access, while some budget STMicro controllers reject a handful of legitimate Type 2 commands. If a programme sees intermittent read failures on specific device models, the underlying NFC controller is the first thing to check.
• Sensing distance and antenna size. Android NFC antennas typically achieve 2-4 cm reliable read distance for consumer stickers, falling to under 1 cm for small keychain tags or wet-inlay tags behind dense substrates. Sensitivity varies by OEM: Pixel 7/8 and Samsung S22/S23 read at the longer end; OnePlus and Xiaomi at the shorter end. For consumer programmes deployed in retail, counter-top tap zones should expect 1-2 cm average and design signage that guides users to tap firmly against the back of the phone.

Free Play Store apps for Android NFC programming (no coding required)

For non-developer users programming NFC tags with Android (marketing teams, small business owners, hospitality operators, event planners, DIY hobbyists) the Play Store has a mature ecosystem of free and freemium apps that handle the underlying android.nfc interaction. This section surveys the apps most commonly used for Android-based NFC tag writing.

• NFC Tools (wakdev): the most popular free Android NFC app. Read and write NDEF records (URL, text, phone, email, SMS, Wi-Fi, Bluetooth, geolocation, app launch via Android Application Record), read raw tag content, verify NDEF compliance, lock tags to read-only, and manage advanced chip features (NTAG password, NTAG mirror, MIFARE Classic sector reads with known keys). Paid Pro tier adds batch operations, MIFARE DESFire support and custom NDEF record types.
• NXP TagWriter: NXP's official app optimized for NTAG and MIFARE chip programming. Strong support for Wi-Fi Simple Configuration records, Bluetooth pairing records, vCard encoding, and NTAG 424 DNA feature configuration (SUN messaging setup, per-tap counter enablement). Free from NXP with no upsell.
• NXP TagInfo: diagnostic app that reads NFC tags in great detail, revealing chip type (model, silicon revision), memory map (configuration pages, counters), NDEF structure (record parsing, validation) and NFC Forum compliance. Essential for QA workflows; reveals whether a tag is genuinely NTAG 213 or a mis-branded compatible chip, and validates that NDEF writes succeeded correctly.
• TagMo: specialized app for Amiibo-style NTAG215-based NFC programming (gaming community tool). Demonstrates advanced NFC capability on Android that isn't possible on iPhone. Not commercial-grade for most programmes, but a useful data point on Android platform capability.
• Tasker and NFC Task Launcher. Automation apps that bind NFC tag UIDs (or NDEF content patterns) to Android device actions (launch app, toggle Wi-Fi/Bluetooth, set sound profile, send SMS, run HTTP request, invoke Google Assistant routine). More flexible than iPhone Shortcuts because of Android's richer action catalog and deeper system access.
• GoToTags Android: commercial app with batch programming capability, CSV import, per-tag unique content generation and enterprise-focused features. Used by customers programming thousands of NFC tags from spreadsheet data on Android for staging or mid-scale deployments.

Android NFC programming step-by-step (consumer workflow)

For users programming a batch of NFC tags with Android without writing code, the workflow is straightforward and fast. One tag can typically be programmed in under 5 seconds. This section walks through the end-to-end process with the tips that improve first-time success rate.

1. Step 1
   Step 1 — Choose the right tag chip for your content. NTAG 213 (144 bytes) fits short URLs (under ~130 chars), simple text, Wi-Fi credentials for most consumer routers, and single-record programmes. NTAG 215 (504 bytes) and NTAG 216 (888 bytes) accommodate longer URLs, vCards, multi-record tags and extended text. For legacy access-control integration, MIFARE Classic or DESFire may be required. Program these with NFC Tools or a dedicated app.
2. Step 2
   Step 2 — Install an NFC writing app. NFC Tools is the most popular all-purpose choice; NXP TagWriter is the official NXP option with better guidance for NTAG-specific features. Both are free from the Play Store. Enable NFC in Settings if it's not already on.
3. Step 3
   Step 3 — Open the app and select the NDEF record type. Common choices: URL (for web links and QR-code-equivalent tags), Wi-Fi (for network-sharing tags), vCard (for contact cards), Text (for plain text content), Android Application Record (AAR) to force a specific app to open when tapped.
4. Step 4
   Step 4 — Enter the content. URLs should be URL-encoded; text is UTF-8 native; Wi-Fi passwords need exact router-matching characters. The app displays the encoded NDEF size so you can verify the payload fits the tag's memory (145 bytes for NTAG 213 user memory, accounting for 4-byte overhead).
5. Step 5
   Step 5 — Tap the tag against the Android phone's NFC antenna area (usually the top-center of the back cover). The app will guide you with a visual prompt; hold the phone still for 1-2 seconds during the write, then release when the success confirmation appears. Failed writes (too-small memory, read-only tag, poor antenna alignment) produce clear error messages.
6. Step 6
   Step 6 — Verify the write by reading the tag back. In most NFC writer apps there's a dedicated Read mode; alternatively, for URL tags, simply bring the programmed tag near the unlocked phone. Android will automatically prompt to open the URL, confirming the NDEF content is correct and the tag is working for end-user consumption.
7. Step 7
   Step 7 — Optionally lock or protect the tag. NFC Forum Type 2 tags support a permanent read-only lock (one-way, irreversible); NTAG 424 DNA supports password-protected writes that can be temporarily secured and later unlocked with the password. Locking is appropriate for public-facing tags where accidental overwrite or malicious tampering could disrupt the programme.

android.nfc developer framework — NfcAdapter, Tag, NdefMessage, intent filters and tag dispatch

For Android developers building custom NFC-integrated apps, the android.nfc package provides full access to the NFC subsystem — which is to say it gives you enough rope to build something excellent or to spend an afternoon wondering why your activity launches twice. This section surveys the core classes, the tag dispatch system and the common implementation patterns that keep you on the excellent side of that line.

• NfcAdapter: the entry point for NFC operations in an Android app. Access via `NfcAdapter.getDefaultAdapter(context)`. Returns null on devices without NFC hardware; check `isEnabled()` to verify NFC is currently turned on. Used to enable foreground dispatch, reader mode, and for NDEF push (deprecated; Android Beam removed in Android 10).
• Tag and TagTechnology classes. When an NFC tag is discovered, Android creates a Tag object containing the chip's UID and supported technologies. TagTechnology subclasses represent the different protocols: Ndef (generic NDEF read/write), MifareClassic (MIFARE Classic sector access), MifareUltralight (Ultralight reads, NTAG family), NfcA / NfcB (low-level ISO 14443 Type A/B), NfcF (FeliCa), NfcV (ISO 15693), IsoDep (ISO 14443-4 for DESFire, JavaCard, EMV).
• NdefMessage and NdefRecord: NDEF data structures. NdefMessage holds an ordered list of NdefRecord objects; each NdefRecord has a TNF (Type Name Format), type (well-known, MIME, URI), ID and payload. The SDK provides convenience constructors for common patterns: `NdefRecord.createUri(uri)`, `NdefRecord.createTextRecord(lang, text)`, `NdefRecord.createApplicationRecord(packageName)` (AAR), `NdefRecord.createMime(mimeType, data)`.
• Tag dispatch system: when Android detects an NFC tag, it matches the tag's NDEF content and TagTechnology against activity intent filters in installed apps and launches the best-matching activity. Intent filter categories include NDEF_DISCOVERED (match specific MIME types or URI schemes), TECH_DISCOVERED (match specific TagTechnology), and TAG_DISCOVERED (catch-all fallback). Proper intent filter configuration is the primary way apps bind to specific NFC experiences without requiring the app to be in foreground.
• Foreground dispatch: for apps in the foreground (e.g., a dedicated scanner app), `NfcAdapter.enableForegroundDispatch()` captures all NFC events regardless of tag dispatch rules, routing them back to the app's `onNewIntent()` handler. Use this for dedicated NFC scanner apps where the user expects all NFC interactions to be handled by the current app.
• Writing NDEF to a tag. Retrieve the Ndef object from the tag, connect (`ndef.connect()`), build an NdefMessage, call `ndef.writeNdefMessage(message)`, close the connection. Error paths handle tag-out-of-range, read-only tags, insufficient memory and unsupported tag types. Production apps wrap this in retry logic with user-friendly error messaging and async handling via Kotlin coroutines.
• Android 14+ refinements: Android 14 added refined NFC reader mode APIs (`NfcAdapter.enableReaderMode()` with polling options), improved handling of multiple tags in the field, and cleaner lifecycle semantics. Legacy code written against Android 5-10 APIs continues to work, but new projects should use the reader-mode APIs for cleaner tag discovery control.
• Android 16 / 17 changes — important for new builds. Per Google's developer documentation: (1) Android 16 routes NFC tags carrying http:// or https:// URI records through `ACTION_VIEW` instead of `ACTION_NDEF_DISCOVERED`, so apps that previously matched on NDEF intent filters for web URLs need to add an `<intent-filter>` for `ACTION_VIEW` with their domain (or rely on Android App Links). (2) Android 16 introduced an NFC tag-scan allowlist UI: on first NFC intent, the user is asked to allow the app to be launched by NFC. Use `NfcAdapter.isTagIntentAllowed()` to check, and `NfcAdapter.ACTION_CHANGE_TAG_INTENT_PREFERENCE` to prompt the user again. The control sits at Settings > Apps > Special app access > Launch via NFC. (3) Android 17 (API level 37) deprecates `ACTION_TAG_DISCOVERED` in favour of `ACTION_NDEF_DISCOVERED` / `ACTION_TECH_DISCOVERED`. (4) Apps targeting SDK > Build.VERSION_CODES.BAKLAVA must protect their NFC-receiving activities with `android:permission="android.permission.DISPATCH_NFC_MESSAGE"` so only the NFC system service can dispatch intents to them; stopped apps no longer receive NFC intents.
• Permissions and manifest declaration. NFC apps must declare `<uses-permission android:name="android.permission.NFC" />` and `<uses-feature android:name="android.hardware.nfc" android:required="true" />` in AndroidManifest.xml. The permission is normal-level (granted at install without user prompt). The feature declaration prevents installation on NFC-less devices when uploaded to the Play Store with `android:required="true"`; set to `false` if the app has graceful fallback for non-NFC devices.
• Coroutine-safe tag operations. Modern Kotlin codebases wrap `ndef.connect()`, `ndef.writeNdefMessage()` and `ndef.close()` inside `withContext(Dispatchers.IO) { ... }` to keep the main thread responsive. A tag write typically completes in 50-200 ms; on slower phones or with large NDEF payloads it can exceed 500 ms, which is enough to cause ANR dialogs if run on the main thread. Always dispatch to IO and surface a cancellable progress indicator to the user.

Advanced Android NFC — MIFARE Classic, MIFARE DESFire, NTAG 424 DNA, Host-based Card Emulation

Beyond NDEF read/write, Android's unrestricted NFC access enables programmes that aren't possible on iPhone. MIFARE Classic Crypto1 authentication, MIFARE DESFire AES sessions, NTAG 424 DNA SUN verification, and Host-based Card Emulation where the phone itself emulates an NFC card to external readers. This section surveys the advanced capabilities.

• MIFARE Classic programming: use the MifareClassic TagTechnology class to authenticate with sector keys (default keys, custom keys from key-management), read/write 16-byte blocks, and modify sector-access bits. Common for legacy access control integration, gym-checkin, public-transit fare cards. The Classic 1K has 16 sectors of 64 bytes each; Classic 4K has 40 sectors. Classic's Crypto1 cipher has known vulnerabilities; production programmes should migrate to DESFire.
• MIFARE DESFire EV1/EV2/EV3 programming — use IsoDep TagTechnology to send APDU commands compliant with the MIFARE DESFire command set (authenticate with AES/3DES keys, create applications, read/write files). DESFire is the modern successor to Classic, with AES-128 authentication, multiple file types (standard, backup, value, linear record, cyclic record) and per-application key management. Used for high-security access control (NYC OMNY, London TfL replacement), student-ID programmes and stadium access.
• NTAG 424 DNA SUN message verification. NTAG 424 DNA generates a cryptographically signed URL on each tap (Secure Unique NFC Message, SUN). Android apps using IsoDep or NfcA can read the SUN-mirrored NDEF or authenticate directly against the DNA chip's AES keys to verify the tag is genuine (not a clone) and has not been tampered with. Used for luxury authentication (handbags, wine, cosmetics), pharmaceutical anti-counterfeit and product-provenance programmes.
• ISO 15693 (ICODE SLIX) programming. Use NfcV TagTechnology for ISO 15693 tags (ICODE SLIX, ST25DV). ISO 15693 operates at 13.56 MHz with longer read range than ISO 14443 (up to 1-1.5 meters), making it suitable for inventory and healthcare programmes where ISO 14443 close-range scanning isn't practical. Proud Tek supplies ICODE SLIX-based tags for these use cases.
• Host-based Card Emulation (HCE). Android 4.4+ lets apps emulate contactless cards to external readers. Use a HostApduService to receive APDU commands from the reader and respond with emulated-card data. Used for transit apps (Google Wallet, Apple-style but on Android), loyalty programmes that deliver digital membership cards, access-control apps that make the phone a key. HCE is the mechanism behind Google Pay, Samsung Pay (partially), and countless branded transit apps.
• HCE-F and FeliCa. Android 7+ added HCE-F for FeliCa emulation (NfcF), enabling Japanese transit-card emulation (Suica, Pasmo, JR). Less widely used outside Japan but important for programmes targeting that market.
• Secure Element (SE): some Android devices include an embedded Secure Element for hardware-backed credential storage (Google Pixel with Titan M, Samsung with Knox). HCE on these devices can leverage SE for key storage. Older devices may offer UICC-based SE via the SIM card. Enterprise programmes with high-security requirements (payment, government ID) rely on SE-backed HCE rather than pure software HCE.
• IsoDep APDU example: sending a MIFARE DESFire SelectApplication command from an Android app: `val isoDep = IsoDep.get(tag); isoDep.connect(); val response = isoDep.transceive(byteArrayOf(0x90.toByte(), 0x5A, 0x00, 0x00, 0x03, 0xF0.toByte(), 0x00, 0x01, 0x00))`. The response byte array ends in 0x91 0x00 for success. Wrap APDU exchanges in try/catch for TagLostException (user moved the card away mid-exchange); on catch, prompt the user to retap and retry from the last checkpoint.
• Transceive timeout tuning: `IsoDep.setTimeout(ms)` controls the NFC stack's per-APDU timeout. Default is 300-500 ms depending on OEM. For long-running DESFire operations (ChangeKey with AES-256 session, large file reads) raise to 2000-3000 ms. For quick authenticated reads, keep default to detect tag-out-of-field quickly. Over-long timeouts cause poor user experience when the tag is accidentally moved away; too-short timeouts cause false failures on slow DESFire operations.

Tasker, Automate and NFC-triggered automation on Android

Android's more permissive system access lets end users build rich NFC-triggered automation without writing a line of code — the rare corner of the platform where a sticker by the bed can do more than most apps. Tasker, Automate and similar apps are popular for personal productivity, home automation, accessibility and small-business workflows. This section covers the automation layer.

• Tasker NFC profiles: Tasker is a long-standing Android automation app. Create a profile with "NFC Tag" trigger (matched by tag UID or NDEF content), and attach task actions: launch app, navigate to specific app screen via deep link, toggle Wi-Fi/Bluetooth/Mobile Data, set volume/sound profile, run HTTP request to a webhook, send SMS, dim screen brightness, run Tasker scene. Extremely flexible; supports complex conditional logic via Tasker variables.
• Automate (LlamaLab): visual flowchart-based automation app. NFC tag triggers similarly bind to UID or NDEF content. Designed to be more approachable than Tasker's text-based configuration; used by less-technical users and for quickly prototyping automation flows.
• Use cases: bedside "goodnight" tag sets alarm, enables DND, turns off Wi-Fi; car dashboard tag starts navigation, connects to car Bluetooth, launches music; office entry tag silences phone, opens work calendar; home entry tag turns on lights via webhook to smart-home hub; workout tag opens fitness tracker and starts timer; kitchen recipe tag opens recipe app to specific recipe URL.
• Automation layering with NDEF content. Programmes can layer multiple capabilities. The tag's NDEF URL record provides default behavior on any NFC-capable device (Android and iPhone both); the automation app provides enhanced behavior specifically for Android users who have bound the tag to their own flow. This layered approach works well for membership tags, venue tags and multi-device households.
• Accessibility NFC workflows: Android's accessibility services allow NFC automation for accessibility use cases (large-button "call mom" tag for elderly users, "make a note" tag for voice-capture). These use cases benefit from Android's richer system access compared to iPhone Shortcuts.
• Enterprise automation: Android Enterprise and MDM-managed fleets can deploy NFC-triggered workflows via managed automation tools (SOTI MobiControl, Microsoft Intune, VMware Workspace ONE). Useful for field-service, retail associates, hospitality staff where consistent NFC-driven behavior across a managed device fleet is important.

Kotlin code patterns for production Android NFC apps

Moving from Play Store apps to a custom Android app requires concrete code patterns for the most common NFC workflows: reading NDEF from any tag, writing a URL, authenticating to NTAG 424 DNA, and handling foreground dispatch safely across the Activity lifecycle. The patterns below are the ones Proud Tek's integrator team has iterated across ~40 Android NFC projects; they compile cleanly against API 29+ and follow modern Kotlin + AndroidX conventions.

• Minimal manifest: declare the NFC permission and hardware feature: `<uses-permission android:name="android.permission.NFC" />` plus `<uses-feature android:name="android.hardware.nfc" android:required="true" />` inside the `<manifest>` block. For URL tag dispatch, add an `<intent-filter>` on your target Activity with `<action android:name="android.nfc.action.NDEF_DISCOVERED" />` and a `<data android:scheme="https" android:host="yourdomain.com" />` filter.
• Read NDEF from any tag (onNewIntent). Inside `onNewIntent(intent)`: `val rawMessages = intent.getParcelableArrayExtra(NfcAdapter.EXTRA_NDEF_MESSAGES); val ndefMessages = rawMessages?.map { it as NdefMessage }; ndefMessages?.firstOrNull()?.records?.forEach { record -> if (record.tnf == NdefRecord.TNF_WELL_KNOWN && record.type.contentEquals(NdefRecord.RTD_URI)) { val uri = record.toUri(); /* handle uri */ } }`. Always call `setIntent(intent)` to update the Activity's current intent reference.
• Write a URL to a writable tag. `val tag: Tag = intent.getParcelableExtra(NfcAdapter.EXTRA_TAG) ?: return; val ndef = Ndef.get(tag) ?: return; val uri = Uri.parse("https://example.com/p/ABC123"); val record = NdefRecord.createUri(uri); val message = NdefMessage(arrayOf(record)); try { ndef.connect(); if (ndef.isWritable && ndef.maxSize >= message.byteArrayLength) { ndef.writeNdefMessage(message) } } finally { ndef.close() }`. Wrap in IO dispatcher.
• Foreground dispatch setup: in `onResume()`: `val intent = Intent(this, javaClass).addFlags(Intent.FLAG_ACTIVITY_SINGLE_TOP); val pendingIntent = PendingIntent.getActivity(this, 0, intent, PendingIntent.FLAG_MUTABLE); nfcAdapter?.enableForegroundDispatch(this, pendingIntent, null, null)`. In `onPause()`: `nfcAdapter?.disableForegroundDispatch(this)`. This captures every tap while the Activity is foreground, overriding normal dispatch filtering.
• Reader-mode (Android 10+) alternative. `nfcAdapter?.enableReaderMode(this, { tag -> handleTag(tag) }, NfcAdapter.FLAG_READER_NFC_A or NfcAdapter.FLAG_READER_SKIP_NDEF_CHECK, null)`. Reader mode gives the app exclusive, low-latency tag access without the system NDEF dispatch indirection. Preferred for high-throughput apps (POS, ticket gate, inventory scanner) where every millisecond matters.
• NTAG 424 DNA SUN URL verification (server side). The Android app side is simply a URL read; the cryptographic verification happens on your backend. The app pattern: (1) read NDEF, (2) extract URL, (3) POST the URL to your backend `/verify` endpoint, (4) backend uses the tag's pre-provisioned AES-128 meta-key to compute expected SUN mirror values from UID + counter embedded in the URL, (5) compare against URL-provided SUN. Return boolean + human-readable result. Client just renders the result.
• Handling malformed or counterfeit tags. Wrap every `ndef.connect()` and `isoDep.transceive()` call in try/catch for TagLostException, IOException, FormatException, and NullPointerException. Present user-friendly errors: 'Move closer' (TagLostException), 'Not a supported tag' (null Ndef instance), 'Tag is full' (maxSize check), 'This tag cannot be authenticated' (CMAC mismatch). Never expose stack traces to end users; log them to Firebase Crashlytics or equivalent for diagnosis.
• Testing on a physical device. Android Studio emulators do not support NFC. Minimum test fleet for consumer programmes: Pixel 6 or 7 (stock Android), Samsung Galaxy S22 or S23 (OneUI), one OnePlus or Xiaomi (non-stock OEM overlay), and one budget phone (e.g., Samsung A-series) to catch chipset edge cases. Automated testing of NFC flows is limited to the UI layer (Espresso tests that simulate tag intents); the actual NFC interaction must be tested manually.

Proud Tek Android-tested NFC products and engagement for Android NFC programmes

As with iPhone programmes, the choice of NFC product is material to Android programming success. Proud Tek's NFC product range covers the chip families Android customers most often need. From NTAG 213 for consumer marketing through MIFARE DESFire EV3 for encrypted access control. This section surveys the product-to-use-case fit and the engagement model for Android-focused programmes.

• NTAG 213 stickers and cards. Most cost-effective choice for Android URL, text and simple Wi-Fi record programmes. 144 bytes of user memory, compatible with every Android phone's NFC radio and every Play Store writing app. Ideal for Google Review cards, business cards, restaurant menus, event wristbands and promotional campaigns.
• NTAG 215/216 stickers — mid and high-memory variants for programmes needing 504 or 888 bytes respectively. NTAG 215 is notable for Amiibo community use; NTAG 216 for full-content vCards or multi-record tags. Android programming workflow is identical to NTAG 213.
• NTAG 424 DNA tags. Advanced chip with per-tap cryptographic signature (SUN message) and password-protected writes. Android apps can both write the DNA configuration (via NXP TagWriter or custom app with IsoDep APDUs) and verify the SUN signature at read time. Used for luxury authentication, pharmaceutical anti-counterfeit and high-value digital-passport programmes.
• MIFARE Classic 1K/4K cards. Legacy access control and transit card chip. Android supports full Classic read/write via MifareClassic TagTechnology with sector key authentication. Proud Tek supplies Classic cards with factory-default keys and customer-provided key sets as required.
• MIFARE DESFire EV1/EV2/EV3 cards — modern AES-encrypted access control chip. Android IsoDep APDU access enables full DESFire programming: application creation, file creation, key provisioning, encrypted reads/writes. Preferred chip for high-security modern access control and transit replacement programmes.
• MIFARE Ultralight C and EV1 tags — memory-optimized alternatives to NTAG 21x for large-volume disposable programmes (event tickets, laundry tags, field-trial consumables). Ultralight has smaller memory (48-128 bytes) but lower per-unit cost. Fully Android-compatible.
• Engagement model: Proud Tek's free Android-tested sample kits (100-500 tags across chip families) let Android programmers validate compatibility and workflow. Pre-encoding service scales from 1k-1M+ tags with per-tag unique content (unique URL serialization, per-tag MIFARE Classic key provisioning, DESFire application-key deployment). Production QA includes Android-specific read-verification on sampled lots, with chip-family documentation and key-handoff procedures tailored to Android integration projects.

FAQ