ZHZN Android manufacturer acceptance and sign-off

Manufacturing checklist / 制造验收清单: Photo printing, remote lock, power bank, cameras and all configured features / 照片打印、远程锁、充电宝、摄像头及全部配置功能. Complete the serial-specific checklist alongside this APK sign-off; optional hardware and actual physical execution need separate evidence.

Open the illustrated installation atlas and cabinet checklist.

Instructional illustration; screens and device details vary. Follow the exact steps and approved release record below.

For the factory technician, QA signer and shipping coordinator. Read Android install and operation first. A machine leaves the line only after physical tests, correct identity/accessories and the required server records have been reviewed for the same cabinet.

Know which acceptance record you are completing

There are three records. Keep all their references in the handover pack:

The Android handwritten certificate does not create the Partner build signature. A green local Summary, a successful diagnostic upload and the Partner FAT's readyForSignoff also mean different things. Verify the actual server records; do not substitute a screenshot of a green screen for them.

1. Establish the cabinet and build record

Record the physical serial, model, board revision, factory, batch/order reference, installed APK version, Android version, signer/digest reference, board firmware when available, port/protocol/module and tray layout.

Use a manufacturer credential scoped to its own ZHZN builds (machines:build), or an authorized full-admin workflow, to create/update:

• PUT /api/v1/machines/{no}/build: build/manufacturer/model/batch details.
• GET /api/v1/machines/{no}/build: review the actual saved build.
• GET /api/v1/machines/build/tests: obtain the current FAT test catalog.

The current operator factory view is for reading records; do not look for a factory-signing button there that is not implemented. Use the approved bench client or Partner API for the build write/signature steps below. The cabinet must stay unclaimed until its intended operator receives it.

Finish APK installation, Home/device-owner setup and identity mapping. Do not clone app data. If accessories will be provisioned using bootstrap-authenticated bench tooling, record them before device enrolment as described below; once enrolled, the cabinet requires its device credential for that endpoint.

2. Test the physical machine before signing anything

Test the actual cabinet, not a matching cabinet or simulator. Keep the observed results, time, technician and evidence references. Exercise faults and recovery in a controlled bench setup.

Use pass for an observed pass, fail for a fault, skip for an unperformed test, and not_fitted only for a genuinely absent supported optional subsystem. Do not turn a failed or untested fitted reader into not_fitted to clear a gate. Record all ten dispositions so the next owner can distinguish absence from missing evidence. The server's current catalog/readiness response remains the authority on whether a factory signature is allowed.

Also execute the shopper scenarios in Shopper acceptance tests: correct prices/currency, QR/card purchase, duplicate attempts, cancellation/late taps, faults, offline recovery, required age checks and any enabled optional experience. Keep unresolved release constraints attached to the cabinet; a software limitation is not cured by signing a paper form.

Record the intended destination country, operator currency, reader payment profile and processor/settlement account. Acceptance is for that tested configuration. The current Spark integration permits USD only; the current Stripe QR integration rejects three- and four-decimal currencies and UYI, and requires one product and one unit per checkout when capturing after delivery. Stripe's account/country/payment-method availability still applies. Native MDB card also accepts one product line and one unit per purchase, online or offline. Its amounts must match the fitted reader's currency and decimal places. Complete a real destination-profile transaction and its refund/reconciliation check; neither a successful software test nor this certificate establishes global payment readiness. See Operator handover.

3. Record fitted accessories against this cabinet

Photo printing, power-bank sharing and a Nayax reader are independent options. Record what is physically fitted, and scan/enter the real identifier where required. Preserve leading zeros.

The current Android Factory test and operator views do not expose accessory scan/Fitted/Not fitted write controls. Have the authorized bench tooling perform POST /zhzn/factory-attach; do not tell a line technician to find a nonexistent button.

Example body for an actually fitted power-bank unit:

{
  "kind": "powerbank",
  "attached": true,
  "scanned": "REPLACE_WITH_ACTUAL_DOOR_QR_OR_SUPPORTED_ID",
  "source": "qr"
}

The endpoint uses cabinet authentication, not the manufacturer's X-API-Key. Before enrolment, approved bench tooling can use the bootstrap x-device-secret with this cabinet's equipmentNo. After enrolment it must use the established x-device-key and witness workflow. Do not issue another key or extract credentials into ordinary documents to make this call.

Review bound, bindError, likelyMachineId, attachments and blockers in the response. A fitted power bank or Nayax must bind without an error. An attached:false write can release an existing binding; use it only after confirming the accessory is actually absent. Do not send a blanket absent payload over a cabinet with fitted hardware.

If appropriate cabinet-authenticated tooling is unavailable after enrolment, escalate to the provisioning owner. The docs do not imply an API credential can be used in place of a device credential.

4. Run the APK Factory test

Before this step, have the approved provisioning process make the plant's Partner API credential available to the APK as a readable factory.api-key. The APK searches its external/internal app files and the public fallback /sdcard/kioskx/factory.api-key; Android storage policy can make the public fallback unreadable, so verify the actual FAT upload. Without a usable authorized key, the native FAT filing and signature gate cannot complete. This is separate from the cabinet's enrolment credential.

The APK caches this key in preferences. Deleting the provisioning file alone does not remove the cached credential. Have the release/provisioning owner include its removal or revocation in the approved bench-credential lifecycle; do not clear all app storage and destroy device identity/reports to remove it.

1. Open the PIN service menu and choose Factory test / 工厂测试.
2. Run the displayed steps. Grant camera, microphone and the correct USB permissions where needed; rerun a step after correcting a permission.
3. Camera: use Capture and inspect the identified camera's picture. Speaker: Play tone and listen. Microphone: Record 2 s — speak now, then inspect the displayed automatic PASS/FAIL and RMS sound level; this step does not provide recording playback.
4. Touch: tap all nine required zones. Screen: Show R/G/B/W pages, then tap through all four colors and inspect the actual panel. Board: inspect its scan; use Rescan after fixing the connection. Confirm the identified serial/USB port, protocol and module.
5. Review every result and the evidence at Summary. Fix/retest failures.

The current on-device sign-off requires all six checks to pass, plus the identified camera and board information. A screen may allow Skip, and its summary may distinguish “no failures” from failed, but a skipped required check does not become eligible for the handwritten certificate. If the approved build omits camera/microphone or another required diagnostic subsystem, escalate the acceptance-profile mismatch rather than claiming it passed.

Board handshake is not every-lane dispense evidence. The current APK's Partner FAT upload contains only observed vmc board-communication and screen screen/touch results. It does not create power, network or dispense passes and does not declare MDB/reader/coin/bill/cooling absent. Queued reports are rebuilt into those same observed rows before replay. File the physical results and fitted/absent dispositions through the bench workflow below; an accepted two-row upload does not make a complete FAT or prove readyForSignoff.

5. Upload and obtain the Android certificate

At Summary, wait for the diagnostic upload and its FAT upload result. Use the provided retry action for a network failure after connectivity is restored. Read the server reason for a refusal; resubmitting the same rejected data is not a repair. “Queued” means work remains on the cabinet and does not permit ship.

Once the hardware/server blockers are clear, open Acceptance sign-off / 验收签核:

1. Enter Technician name / 技术员姓名 and Employee ID / 员工编号.
2. Optionally enter Factory lot / 生产批次.
3. Read and accept the displayed attestation. Address any clock warning and preserve its evidence; do not alter timestamps to make a record look trusted.
4. Draw the real signature in Sign here with your finger / 请用手指在此签名. Use Clear if needed, then sign again.
5. Submit once. Wait for SIGNED — acceptance certificate issued and record the returned certificate reference. QUEUED or REJECTED is not signed.
6. Confirm the certificate and the cabinet serial in the server/operator read view. If a reply is lost, inspect the saved certificate before signing again.

The physical checks in section 2 must already have been performed. This certificate covers the APK diagnostic/attachment attestation; it does not replace the complete physical FAT record or its separate signature.

6. File truthful final FAT results and sign the Partner build last

Use this sequence to review the complete cabinet evidence before the final Partner signature:

1. Complete the physical tests, accessory provisioning, APK upload and native signature above. Keep all evidence.
2. Through the manufacturer bench workflow, post the actual final subsystem results to POST /api/v1/machines/{no}/build/tests. Include a suite reference, and each result's code, result, detail, testedAt and testedBy. The APK's two observed rows leave the remaining physical tests to this workflow. Review all ten dispositions; do not assume omitted tests passed.
3. GET /api/v1/machines/{no}/build; compare latestResults and testSummary with the real cabinet. Confirm every required test passes and no fitted subsystem is falsely described as absent.
4. Only then submit POST /api/v1/machines/{no}/build/signoff, with the named signer's by, role and evidence/reference note. Keep its response.
5. Read the build again and confirm the factory sign-off. This is the signature the subsequent operator delivery-acceptance workflow requires.

The Partner API uses the authorized manufacturer's X-API-Key. Example final signature body, after evidence and readiness have been verified:

{
  "by": "REPLACE_WITH_ACTUAL_QA_SIGNER",
  "role": "Line QA",
  "note": "REPLACE_WITH_THIS_CABINET_PHYSICAL_FAT_AND_CERTIFICATE_REFERENCES"
}

A Summary rerun uploads the current vmc and screen observations again and can replace those latest results before the Partner signature. It does not replace the other physical subsystem rows. If either observation changes, review the complete saved FAT again before signing; do not use a rerun to ignore a failed physical test. Once the Partner build is signed, it refuses further test changes with 409. Subsequent work needs a service/rework record, not an attempt to overwrite what was signed.

7. Shipping handover

The shipping coordinator checks the same serial across plate, software, build, accessories, certificate and paperwork. Record batch/order, shipping destination, carrier/tracking/consignment as available. Provide the recipient:

• Build and app version/digest references, physical wiring/port map and tray map.
• Full FAT observations, fitted/absent subsystem list and any relevant media.
• Android certificate ID and separate Partner factory-signature record.
• Reader Device Number and other accessory binding references.
• Approved payment methods/features/currency and outstanding limitations.
• Support contact, warranty/service reference and protected credential handover through the fleet's established channel, not printed passwords on the crate.

Power-cycle once more and verify the expected kiosk start, board and network recovery. Ensure it has no operator owner until the intended claim stage. Do not ship on a queued upload/signature, incorrect accessory binding, untested fitted hardware, unresolved unsafe shopper path or missing required record.

8. Warehouse, operator claim and delivery acceptance

A warehouse administrator verifies the certificate and shipment, then records Mark received at USA warehouse in the supported warehouse workflow. Warehouse receipt is not the customer's acceptance and does not make the machine live.

The operator follows Setup: Claim → Locate → Nayax → First fill → Go-live → Done. Existing claimed machines can start at Locate. A claim for another operator's cabinet needs an ownership transfer; never create a new serial to avoid the ownership check.

The Nayax step applies to a fitted reader. Go-live uses paymentsReady, which can be satisfied by either a ready card binding or a configured live Stripe QR path in an enabled currency. A simulated/test-mode QR is not production readiness; a reader settling to a previous owner's Core actor is not an operator-ready binding. A QR-only cabinet needs no invented reader. Production refuses forced go-live while checks are incomplete. The installer must still verify the actual purchase, delivery and settlement before opening to shoppers.

In the operator web machine detail, inspect the build/certificate record and use the host-link/delivery-acceptance workflow. The host card title reflects its state, such as No host linked, Host: or No host. The current Flutter factory card is a read view; do not assume it contains the web acceptance controls. Before acceptance, record the venue/host arrangement, including the supported explicit no-host arrangement and reason when that is the real situation. The API can refuse acceptance while the host arrangement is unresolved.

Inspect shipping damage, verify the actual machine configuration and carry out the shopper acceptance transaction before accepting delivery. A factory signature, warehouse receipt, operator acceptance and go-live are four different milestones; preserve all four.

Completion record for the bench/installer

Use this as a handover checklist, not a substitute certificate:

Related: Android install and operation, Operator handover, Shopper use and support.