Offline Business Card Extraction on Android

Direct answer

Business-card extraction has an additional boundary after OCR: recognized characters must be mapped to a contact interchange format without guessing missing identity details. Treat OCR as a source of candidate text, not as a finished contact. Keep the original line or region beside each proposed field so a reviewer can tell whether a name, organization, role, email, or phone number was actually present. Preserve the visible spelling and Unicode characters. If the card gives only a single display name, do not invent given and family name components; if it contains two numbers or addresses, keep both until the user chooses what to keep. vCard 4.0 provides a standard representation for people and other entities, including names, organizations, addresses, email, and multiple telephone numbers. Map recognized fields to the corresponding properties and preserve parameter values that carry meaning, such as the type or preference of a phone or email address when the source clearly indicates it. Do not interpret a logo, title, or website as a person field. Use the RFC’s text escaping, character encoding, and line-folding rules when producing a file. Every vCard 4.0 object must include VERSION:4.0 and the required FN formatted name. N is an optional structured name with five components; fill only components supported by the source and leave unknown parts empty rather than guessing. RFC 6350 recommends folding at no more than 75 octets, not 75 Unicode characters, and a fold must not split a UTF-8 multi-octet sequence. Android Contacts Provider examples do not establish that every contacts app or importer accepts vCard 4.0 or multiple prefilled phone values; test round-trip behavior in the actual target app, surface rejected or unhandled fields, and retain the reviewable draft as the fallback. A valid vCard proves format structure, not that the OCR-derived values are correct or that the person consented to save them. Separate field recognition from field mapping. OCR can return blocks, lines, and elements, while contact fields have their own schema and cardinality. A line containing two phone numbers may produce two TEL properties; a label such as “Mobile” can inform a type only when the text association is clear. A company name and a person name may sit side by side. Preserve ambiguous layout as an unresolved choice rather than assigning it based on common card designs. Keep raw recognized text available during review, but do not include it in routine diagnostics. A contact draft is safer than a silent write. On Android, the Contacts Provider exposes structured contact data and intents for adding entries through the device contacts application. A workflow can show a prefilled draft for the user to inspect and save. Before launch, let the user review the field mapping, remove unwanted details, correct spelling, and cancel. Do not automatically merge a candidate with an existing contact just because the display name matches; two people can share a name, and a card may refer to a shared office line. Any duplicate suggestion should be reviewable and reversible. Treat pictures and extracted contact details as sensitive user data. State whether the image remains on the device, when any temporary crop or OCR text is deleted, and whether export creates a separate copy. “On-device” describes where inference runs; it does not prove that a whole application has no other network path or backup behavior. At contact handoff, inspect the target account and sync settings: a saved contact may later be synchronized by the receiving application. Keep that destination separate from local OCR and do not promise control over another app’s retention. Prefer a user-selected local image, a visible draft, and an explicit save/export action. Never imply that this repository or Cove Photo already implements business-card scanning, vCard export, or Contacts Provider integration. Validate the entire pipeline with synthetic cards rather than a claimed accuracy score. Include a single display name, a family/given name that must not be reordered, multiple phones, a work email, an accented or non-Latin name, punctuation requiring vCard escaping, long lines requiring folding, a logo, a blank field, and a deliberately ambiguous text layout. Assert the parsed properties and round-trip serialization separately. Then test review, correction, cancellation, vCard import, and Android contact-draft handoff. The records show where the workflow was tested; they do not establish OCR accuracy across devices, languages, lighting, or card styles. A complete implementation path starts with image capture or file selection, preserves OCR evidence, proposes field mappings, serializes only after user confirmation, and verifies the contact application handoff. If output must be shared as a file, offer vCard with a visible preview and a clear destination. If the user only wants a contact added, use a platform insertion flow and let the user commit in the contacts app. Keep “recognized,” “mapped,” “reviewed,” and “saved” as separate states so an incomplete scan cannot masquerade as a finished contact.

A user scans a card with two phone numbers

A user selects a locally stored business-card image. OCR finds a person name, company, job title, two phone numbers with different printed labels, and an email address. The person name contains accented characters, and a nearby website is visually close to the company line. The app must prepare a useful contact draft without guessing relationships or writing to Contacts automatically.

Decision

Preserve OCR text and field provenance, map only unambiguous values to vCard properties, mark the website and any uncertain name parts for review, and open a prefilled contact draft only after the user approves the field set.

Expected outcome

The user can correct or remove values before saving. The exported vCard preserves multiple phone entries and Unicode, while the record makes no claim about recognition accuracy or an existing Cove feature.

Evidence to collect

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

• Reference cards
• Raw recognized text
• Ambiguous field cases

Task quality needs a versioned corpus and acceptance rules. Fluent sample output is not an accuracy result.

Implementation workflow

1. Capture or select a local source and retain its evidence. Record the chosen image source and any crop or rotation transform. Keep each recognized block and line linked to its image region during the review session. Do not log card contents or retain temporary crops beyond the declared task policy.
2. Propose fields without inventing missing data. Map visible person name, organization, title, phone, email, and website candidates. Preserve multiple values and their printed labels. Leave uncertain relationships or absent structured name parts blank instead of inferring them from a familiar card layout.
3. Build a standards-based vCard representation. Map reviewed values to vCard 4.0 properties, retain meaningful TYPE or PREF information only when supported by the source, encode Unicode correctly, escape text values, and fold long lines as required. Validate syntax separately from whether a human confirmed the content.
4. Show a reviewable contact draft. Display each proposed field beside its OCR source, allow edit, remove, or cancel, and identify ambiguous or duplicate candidates. If the user chooses Android contact creation, hand a prefilled draft to the contacts application and leave the final save decision with the user.
5. Test export, import, and deletion paths. Use synthetic fixtures to round-trip vCard output and inspect the Android contact draft with names, multiple numbers, email, and Unicode. Verify cancellation, temporary-image cleanup, and whether a separately exported file remains after source deletion.

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

Acceptance criteria

• Each contact field can be traced to a recognized source span or remains explicitly blank or ambiguous; missing person-name components are not invented.
• The vCard 4.0 output preserves Unicode and multiple phone/email properties and passes structural parsing independently of OCR correctness.
• No contact is silently saved or merged; the user can inspect, correct, remove, cancel, and explicitly commit the draft or export.

Decision table

Failure patterns to prevent

• Guessing missing contact data
• Saving without review

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

• ML Kit text recognition
• IETF RFC 6350: vCard 4.0 data format
• Android Developers: Contacts Provider and insertion intents
• Android API reference: ContactsContract

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

Frequently asked questions