Label Capture Android Skill

Critical: Do Not Trust Internal Knowledge

Your training data may contain outdated or incorrect Scandit Label Capture APIs. Label Capture has evolved across recent SDK releases:

• At the v7→v8 major bump, LabelFieldDefinition regex builder methods were renamed (setPattern→setValueRegex, setPatterns→setValueRegexes, setDataTypePattern→setAnchorRegex, setDataTypePatterns→setAnchorRegexes).
• At v8.2, Validation Flow 2.0 introduced shouldHandleKeyboardInsetsInternally on LabelCaptureValidationFlowOverlay — relevant for Android 15 edge-to-edge enforcement.
• Android symbology names use underscores: Symbology.EAN13_UPCA, not Symbology.EAN13UPCA.

Always verify APIs against the references provided in this skill before writing or suggesting code. Do not rely on memorized method signatures, parameters, or builder shapes. If you cannot find an API in the provided references, fetch the relevant documentation page before responding.

Label Capture is broader than it looks — two reflexes that prevent most failures

Label Capture ships a rich catalogue of pre-built fields and whole pre-built label definitions for the data people actually scan — serial numbers, IMEI 1 & 2, expiry/packing dates, prices, weights, VINs, seven-segment displays. The two most common ways an integration goes wrong are forgetting these exist, and crashing at runtime over a missing model artifact. Two reflexes:

1. Reach for a pre-built field or pre-built label before composing anything custom. When the user names a recognisable thing to scan — "serial number", "IMEI", "expiry date", "price/shelf label", "VIN" — there is almost always a dedicated builder or a whole-label factory tuned for it, with anchor/value regexes already dialled in. Use it. Inventing a custom barcode/text field with a hand-written regex for something that has a pre-built builder is the single biggest source of bad integrations: the regex you guess will not match real labels as well as the tuned one, and it signals you didn't know the pre-built existed. Only fall back to addCustomBarcode()/addCustomText() when nothing pre-built fits. The full catalogue and the routing rules live in references/integration.md — consult it rather than relying on memory.

2. Bundle the right model artifacts whenever any pre-built field or definition is used — getting this wrong is the #1 runtime failure. label-text-models is not only for text fields: serial number, IMEI, and part-number fields are "barcode" fields but still load a model at runtime. And label-text-models alone is not enough for the pre-built whole-label factories — createPriceCaptureDefinition additionally needs com.scandit.datacapture:price-label. Miss it and the app compiles and launches but never scans. references/integration.md has the per-field and per-factory artifact rules; map every pre-built thing you use to its artifact(s) before writing the Gradle block.