Every login request sent from Dragon Guard Handheld includes a stable device identifier and device name alongside the operator’s credentials. The backend cross-references this identity against a per-tenant allow-list managed by a Supreme Admin. If the device is not registered, is marked inactive, or would push the tenant over its plan’s handheld limit, the login is rejected before any session token is issued. This hardware-level gate prevents unauthorized devices from accessing warehouse data even when valid credentials are provided.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/CodexaCP/DG_APK/llms.txt
Use this file to discover all available pages before exploring further.
How the app resolves its device identity
DeviceIdentityService walks a three-step resolution chain every time DeviceId is read. The first non-empty, non-placeholder value found is used.
Attempt to read the Wi-Fi MAC address
The service enumerates all network interfaces and looks for one named The values
wlan0 or containing wifi. If found, it reads the physical (MAC) address bytes and formats them as a colon-separated uppercase hex string.02:00:00:00:00:00 and 00:00:00:00:00:00 are Android’s privacy-placeholder MACs and are explicitly rejected so the chain continues.Fall back to ANDROID_ID
If no real MAC is available — which is the common case on Android 10 and later — the service reads
Settings.Secure.ANDROID_ID from the device’s content resolver. This is a 64-bit hex value unique to each combination of app-signing key, user, and device. It is returned uppercase.Device name resolution
DeviceIdentityService.DeviceName uses DeviceInfo.Current.Name (the friendly device name set in Android settings). If that is blank, it falls back to "{Manufacturer} {Model}".
Fields sent on every login
Both the Grupo MAS and local login endpoints receive the device identity as part of the standard login payload. TheisHandheld flag signals the backend that this is a handheld client and triggers the device allow-list enforcement.
- Grupo MAS primary
- Local fallback
The Grupo MAS endpoint infers
isHandheld from the endpoint path itself (grupomas-handheld-login); the field is not sent explicitly on this path.Android 10+ and MAC address privacy
Starting with Android 10, the OS returns the randomized placeholder02:00:00:00:00:00 instead of the real hardware MAC when an app reads Wi-Fi interface addresses. DeviceIdentityService detects this placeholder and discards it, so ANDROID_ID is sent as deviceId on virtually all modern devices.
When a login attempt fails with
plans.deviceNotAuthorized, the error message returned by the backend includes the deviceId that was rejected — for example:Este handheld no está autorizado para este tenant. MAC/ID: A1B2C3D4E5F6A1B2The Supreme Admin should copy this exact string from the error message and use it when registering the device. Do not attempt to read the ID from Android settings manually — use the value the app itself reports, since it reflects the resolution chain described above.
Backend enforcement rules
The backend validates all four conditions in order before issuing a session token. Failure at any step returns one of the structured JSON error responses shown below.Valid credentials
The username/email and password must authenticate successfully against the identity provider (Grupo MAS or local). A credential failure returns
auth.externalLoginFailed or INVALID_PASSWORD.Device registered
The
deviceId sent on login must exist in the tenant’s authorized device list, managed by a Supreme Admin. An unregistered device returns plans.deviceNotAuthorized.Device active
The device must be in active status. Devices can be deactivated without being removed from the allow-list. An inactive device returns
plans.deviceInactive.Plan limit not exceeded
The tenant’s active handheld count must be within the limit set by its subscription plan. Exceeding the limit returns
plans.deviceLimitExceeded.Device error codes
| Error key | Meaning | How to resolve |
|---|---|---|
plans.deviceNotAuthorized | The deviceId sent has never been registered for this tenant | Supreme Admin must add the MAC/ID (shown in the error message) to the tenant’s device list |
plans.deviceInactive | The device is registered but has been deactivated | Supreme Admin must set the device status back to active |
plans.deviceLimitExceeded | The tenant has reached the maximum number of concurrent active handhelds allowed by its plan | Upgrade the plan, or deactivate a device that is no longer in use |
Device registration workflow (Supreme Admin)
Attempt login on the handheld
Ask the operator to enter their credentials on the device and tap Iniciar sesión. If the device is not yet registered, the login will fail and display an error message containing the device’s
deviceId.Record the MAC/ID from the error message
The error message follows the pattern:Copy the full
deviceId string exactly as shown. This is the value the backend will validate on future login attempts.Open the Supreme Admin panel
Log in to the Dragon Guard web admin interface with Supreme Admin credentials and navigate to the tenant’s Handhelds or Dispositivos autorizados section.
Add the device
Create a new device entry using the
deviceId copied in Step 2. Set the display name to a recognizable label (location, operator name, or model). Set the status to Active.Verify the plan limit
Confirm that adding this device does not push the tenant over its active handheld plan limit. If it would, either deactivate an unused device or upgrade the plan before proceeding.