An Android and AI glasses device pool dual lock scheduling method

Abstract

This invention provides a dual-lock scheduling method for Android and AI glasses device pools. It includes using a device pair consisting of AI glasses and paired Android phones as the smallest scheduling unit, constructing a dual-lock mechanism of host-side cross-process file locks and AI glasses device-side file locks. The scheduling host first acquires the host-side file lock to achieve multi-process mutual exclusion, then queries the device-side lock status via ADB, classifying it into four device states: idle, occupied, inconsistent, and unknown. Dual-lock synchronization configuration is performed only on idle device pairs, achieving atomic allocation of device pairs. After testing, the device-side lock file and host-side occupied flag are cleared sequentially to complete atomic release. A consistency recovery process is also added to automatically repair lock state inconsistencies caused by process abnormalities, power outages, and network interruptions. The beneficial effects of this invention are: significantly improving device utilization, operational stability, and maintenance efficiency of the AI ​​glasses and Android terminal automated testing cluster.

Description

Technical Field

[0001] This invention relates to the field of automated testing technology for Android and AI glasses, and in particular to a dual-lock scheduling method for Android and AI glasses device pools. Background Technology

[0002] With the rapid development of virtual reality and smart wearable technologies, AI glasses have been widely used in consumer, industrial, and medical fields. The iteration speed of AI glasses firmware and accompanying Android mobile apps is accelerating, and the industry generally adopts a model combining automated testing with CI / CD continuous integration pipelines to ensure product quality. In large-scale testing scenarios, test servers simultaneously connect to multiple AI glasses and multiple paired Android phones, forming a test device cluster. Multiple R&D and testing personnel, as well as multiple CI / CD pipelines, concurrently submit automated test tasks. Because test scenarios such as Bluetooth pairing, photo / video recording, and firmware upgrades are exclusive, a single automated test case must exclusively use a device pair consisting of "one AI glasses + one paired Android phone" during its execution. If the device is occupied by multiple tasks simultaneously, it will directly lead to test case execution failure, script conflicts, and in severe cases, damage to the AI ​​glasses' file system.

[0003] Current scheduling solutions for test device pools in the industry have many shortcomings, failing to balance concurrency efficiency, device mutual exclusion, and exception handling requirements. The first mainstream solution involves setting an idle / occupied boolean flag in the configuration file to record the device status. This method is only suitable for single-process scenarios. In a multi-process, multi-task concurrent environment, different processes will read independent copies of the flag in memory. Multiple tasks may simultaneously determine that a device is idle and preemptively occupy it, causing device conflicts and widespread test task failures. The second solution involves building a task request queue on the scheduling server to execute all test tasks serially. While this method completely avoids device preemption conflicts, the multiple independent devices connected to the test server cannot work in parallel, resulting in extremely low device utilization and significantly slowing down the overall efficiency of the CI / CD pipeline, failing to meet the testing needs of high-frequency iterations.

[0004] The third approach employs a single host-side mutual exclusion mechanism to manage the device, including host-local file locks, Redis distributed locks, and database row-level locks. This approach can achieve mutual exclusion between multiple processes on the host, but it only verifies the logical occupancy status on the host side and cannot perceive the actual operating status of the AI ​​glasses device. When unexpected situations occur, such as abnormal exit of the test process, power outage of the test server, network interruption, or residual lock files, a large number of "dirty states" are generated: for example, the host configuration file shows the device is idle, but the AI ​​glasses are still executing the previous test process; or the host marks the device as occupied, but the device has already completed the test and is in an idle state. These dirty states cannot be automatically identified by the system and must be manually logged into the server by maintenance personnel to modify the configuration file and clean up the lock file, resulting in high maintenance costs and slow response times.

[0005] In addition, AI glasses are resource-constrained Android smart devices. Frequent restarts and firmware flashing are routine testing operations. Unordered competition for the device by multiple tasks can cause flashing scripts and audio / video recording scripts to interfere with each other, which not only results in poor test stability but also increases the risk of device hardware damage.

[0006] In summary, existing device scheduling schemes have shortcomings in four core dimensions: multi-process concurrent mutual exclusion, device entity state verification, automatic lock state recovery, and atomic scheduling of devices. They either sacrifice concurrency efficiency to ensure stability or allow concurrency but cannot avoid device conflicts and dirty state issues, making them unsuitable for the use requirements of large-scale AI glasses and Android terminal automated testing clusters. Based on this, this invention proposes a dual-lock scheduling method for Android and AI glasses device pools to solve the various defects of existing technologies. Summary of the Invention

[0007] To address the problems in existing technologies, this invention provides a dual-lock scheduling method for Android and AI glasses device pools. It uses a device pair consisting of AI glasses and paired Android phones as the smallest scheduling unit, constructing a dual-lock mechanism combining a host-side cross-process file lock and an AI glasses device-side file lock. The scheduling host first acquires the host-side file lock to achieve multi-process mutual exclusion, then queries the device-side lock status via ADB, and classifies the device into four states: idle, occupied, inconsistent, and unknown, based on the host-side occupancy flag. Dual-lock synchronization configuration is performed only on idle device pairs, achieving atomic allocation of device pairs. After testing, the device-side lock file and the host-side occupancy flag are cleared sequentially to complete the atomic release. Simultaneously, a consistency recovery process is added to automatically repair inconsistencies in lock states caused by process anomalies, power outages, and network interruptions. This process can balance the concurrent execution capability of multiple tasks with the authenticity of device occupancy status. It does not require the deployment of a resident process on the AI ​​glasses, has strong cross-platform compatibility, and can automatically handle dirty states. It significantly improves the device utilization, operational stability, and maintenance efficiency of AI glasses and Android terminal automated testing clusters. It is suitable for CI and CD automated testing scenarios of AI glasses firmware and accompanying APPs. It solves the shortcomings of existing device scheduling schemes in four core dimensions: multi-process concurrent mutual exclusion, device entity status verification, automatic lock state recovery, and atomic scheduling of devices.

[0008] This invention discloses a dual-lock scheduling method for Android and AI glasses device pools, applied to an automated test cluster consisting of a scheduling host and multiple device pairs. Each device pair includes one AI glasses and one paired Android phone. The method includes a device pair allocation process, a device pair release process, and a lock state consistency recovery process. The device pair allocation process includes the following steps: Step 101: The scheduling host receives a test task request carrying the project model, occupant identifier, maximum waiting time, and polling interval. Step 102: The scheduling host attempts to acquire a cross-process file lock on the host side. If the lock acquisition fails, it will continue to retry according to the polling interval until the lock is successfully acquired or the maximum waiting time is reached. Step 103: While holding the cross-process file lock on the host side, the scheduling host reads the preset configuration file and filters out candidate device pairs that are enabled and whose project model matches the test task request. Step 104: For each candidate device pair, the scheduling host sends a query command to the corresponding AI glasses via ADB to detect the existence status of the device side lock file in the internal storage directory of the AI ​​glasses. Here, ADB refers to Android Debug Bridge. Step 105: The scheduling host combines the host-side occupancy flag in the configuration file with the device-side lock file existence status to determine whether the candidate device pair is in one of four states: idle, occupied, inconsistent, or unknown. Step 106: The scheduling host only performs allocation operations on candidate device pairs whose status is idle, synchronously completes the writing of the device-side lock file and the update of the host-side occupancy flag, and releases the host-side cross-process file lock and returns the device lease after successful allocation. Step 107: If all candidate device pairs fail to be allocated, the scheduling host releases the host-side cross-process file lock and goes to sleep, waiting for the polling interval before re-executing the allocation process. If the allocation fails to be successful within the timeout period, a timeout exception is thrown.

[0009] In a further improvement to this invention, after the test task is completed, the scheduling host invokes the device pair release procedure in the finally semantics. The device pair release procedure includes the following steps: Step 201: The scheduling host acquires a cross-process file lock on the host side; Step 202: The scheduling host locates the target device pair to be released based on the device pair's unique identifier or device number; Step 203: The scheduling host verifies whether the occupant identifier in the occupant metadata of the target device pair is consistent with the occupant identifier requested for release. If they are inconsistent and the forced release mode is not enabled, the release is refused and an exception is thrown. Step 204: The scheduling host queries the device-side lock file in the AI ​​glasses via ADB. If the lock file exists, a deletion command is issued. If deletion fails and the forced release mode is not enabled, an exception is thrown. Step 205: The scheduling host clears the host-side occupancy flag and occupancy metadata, and updates the configuration file using a temporary file atomic replacement method; Step 206: The scheduling host releases the host-side cross-process file lock and returns the release result to the device.

[0010] The present invention is further improved, and the lock state consistency recovery process includes the following steps: Step 301: The scheduling host receives a recovery request containing the device's unique identifier, occupant identifier, and remote lock deletion switch parameters; Step 302: The scheduling host acquires the host-side cross-process file lock, re-detects the host-side occupancy flag and the device-side lock file status of the target device pair, and determines the current lock status; Step 303: If the inconsistency is determined, the scheduling host performs repair according to the state combination: if the host side is occupied and the device side is unlocked, the host side occupancy flag and occupancy metadata are cleared; if the host side is not occupied, the device side is locked and the remote lock deletion switch is turned on, the device side lock file in the AI ​​glasses is deleted. Step 304: After the repair is completed, the scheduling host writes the person who performed the recovery operation and the recovery time into the occupied metadata as audit information, releases the cross-process file lock on the host side, and returns the latest status of the device.

[0011] In a further improvement to this invention, in step 102, the host-side cross-process file lock is implemented based on the system interface. The Linux / macOS platform uses the fcntl.flock system call, and the Windows platform uses the msvcrt.locking runtime library call to perform the locking operation in non-blocking exclusive mode.

[0012] The present invention is further improved in that, in step 105, the determination rules for the four states are as follows: if the host-side occupancy flag is not occupied and the device-side lock file does not exist, it is determined to be idle; if the host-side occupancy flag is occupied and the device-side lock file exists, it is determined to be occupied; if the host-side occupancy flag and the device-side lock file state do not match, it is determined to be inconsistent; if the ADB command does not respond or returns an exception, it is determined to be unknown.

[0013] The present invention is further improved in that, in step 106, the scheduling host performs an allocation operation on the candidate device pair, specifically including: 106a, the scheduling host generates a lock payload containing the occupant identifier, the unique identifier of the device pair, the project model, the device number, the host information, the process number, the CI and CD contexts, and the acquisition time, and serializes it into a JSON format temporary file, where CI is continuous integration and CD is continuous delivery; 106b, the JSON format temporary file is pushed to the preset remote lock path of the AI ​​glasses via ADB to form a device-side lock file; 106c, the ADB query command is called a second time to verify whether the device-side lock file is effective. If the verification fails, the temporary file in the AI ​​glasses is deleted and the current candidate device pair is abandoned; 106d, after the verification passes, the host-side occupancy flag in the configuration file is set to occupancy, and the lock payload information is written to the occupancy metadata. The configuration file is updated using a temporary file atomic replacement method; 106e, if the configuration file update fails, the device-side lock file in the AI ​​glasses is deleted synchronously to complete the rollback. If the update is successful, the host-side cross-process file lock is released, and a device lease containing device pair information, lock file path, and occupancy information is returned to the test task.

[0014] The present invention is further improved in that, in step 103, the configuration file is a YAML format file, which uniformly stores the static and dynamic information of all device pairs; the static information includes the unique identifier of the device pair, the AI ​​glasses number, the Android phone number, the Appium port, and the project model; the dynamic information includes the host-side occupancy flag bit and occupancy metadata.

[0015] In a further improvement to this invention, in step 104, the AI ​​glasses only reserve a preset internal storage directory for storing device lock files, without deploying a resident service. The read, write, and delete operations of the device lock files are all remotely executed by the scheduling host through ADB commands.

[0016] In a further improvement, the scheduling host provides an HTTP interface to encapsulate the functions of device pair allocation, device pair release, lock status query, and consistency recovery into an interface service for remote CI and CD pipelines and automated testing systems to call.

[0017] The present invention is further improved in that the occupancy metadata stores at least the occupant identifier, the device pair unique identifier, the device number, the lock file path, the acquisition time, and the recovery audit field, which are used for problem tracing and status auditing.

[0018] The beneficial effects of this invention are as follows: This invention provides a dual-lock scheduling method for Android and AI glasses device pools. It uses a device pair consisting of AI glasses and paired Android phones as the smallest scheduling unit, constructing a dual-lock mechanism combining a host-side cross-process file lock and an AI glasses device-side file lock. The scheduling host first acquires the host-side file lock to achieve multi-process mutual exclusion, then queries the device-side lock status via ADB, and classifies the device into four states: idle, occupied, inconsistent, and unknown, based on the host-side occupancy flag. Dual-lock synchronization configuration is only performed on idle device pairs, achieving atomic allocation of device pairs. After testing, the device-side lock file and the host-side occupancy flag are cleared sequentially to complete the atomic release. The system adds a consistency recovery process to automatically repair inconsistencies in lock states caused by process anomalies, power outages, and network interruptions. It can balance the concurrent execution capability of multiple tasks with the authenticity of device occupancy status. It does not require the deployment of a resident process on the AI ​​glasses, has strong cross-platform compatibility, and can automatically handle dirty states. It significantly improves the device utilization, operational stability, and maintenance efficiency of AI glasses and Android terminal automated testing clusters. It is suitable for CI and CD automated testing scenarios of AI glasses firmware and supporting APPs. It solves the shortcomings of existing device scheduling solutions in four core dimensions: multi-process concurrent mutual exclusion, device entity status verification, automatic lock state recovery, and atomic scheduling of devices. Attached Figure Description

[0019] Figure 1 This is a flowchart of a dual-lock scheduling method for an Android and AI glasses device pool according to the present invention; Figure 2 This is a flowchart of a dual-lock scheduling method for an Android and AI glasses device pool according to the present invention; Figure 3 This is a flowchart of a dual-lock scheduling method for Android and AI glasses device pools according to the present invention. Detailed Implementation

[0020] The present invention will now be described in further detail with reference to the accompanying drawings and embodiments.

[0021] Please see Figures 1-3 This invention discloses a dual-lock scheduling method for Android and AI glasses device pools, applied to an automated test cluster consisting of a scheduling host and multiple device pairs. Each device pair includes one AI glasses and one paired Android phone. The method includes a device pair allocation process, a device pair release process, and a lock state consistency recovery process. The device pair allocation process includes the following steps: Step 101: The scheduling host receives a test task request carrying the project model, occupant identifier, maximum waiting time, and polling interval.

[0022] Step 102: The scheduling host attempts to acquire a host-side cross-process file lock. If the lock acquisition fails, it will continue to retry according to the polling interval until the lock is successfully acquired or the maximum waiting time is reached. The host-side cross-process file lock is implemented based on the system interface. The Linux / macOS platform uses the fcntl.flock system call, and the Windows platform uses the msvcrt.locking runtime library call to perform the locking operation in non-blocking exclusive mode.

[0023] Step 103: While holding a cross-process file lock on the host side, the scheduling host reads a preset configuration file and filters out candidate device pairs that are enabled and whose project model matches the test task request. The configuration file is a YAML format file that uniformly stores the static and dynamic information of all device pairs. The static information includes the unique identifier of the device pair, the AI ​​glasses number, the Android phone number, the Appium port, and the project model. The dynamic information includes the host-side occupancy flag and occupancy metadata.

[0024] Step 104: For each candidate device pair, the scheduling host sends a query command to the corresponding AI glasses via ADB to check the existence status of the device-side lock file in the internal storage directory of the AI ​​glasses. Here, ADB refers to Android Debug Bridge. The AI ​​glasses only reserve a preset internal storage directory for storing the device-side lock file, and no resident service needs to be deployed. The read, write, and delete operations of the device-side lock file are all remotely executed by the scheduling host via ADB commands.

[0025] Step 105: The scheduling host combines the host-side occupancy flag in the configuration file with the device-side lock file existence status to determine whether the candidate device pair is in one of four states: idle, occupied, inconsistent, or unknown. The specific determination rules for the four states are as follows: if the host-side occupancy flag is not occupied and the device-side lock file does not exist, it is determined to be idle; if the host-side occupancy flag is occupied and the device-side lock file exists, it is determined to be occupied; if the host-side occupancy flag and the device-side lock file status do not match, it is determined to be inconsistent; if the ADB command does not respond or returns an exception, it is determined to be unknown.

[0026] Step 106: The scheduling host performs allocation operations only on candidate device pairs whose status is idle, simultaneously completing the writing of the device-side lock file and the updating of the host-side occupancy flag. After successful allocation, the host-side cross-process file lock is released and the device lease is returned. Specifically, the scheduling host's allocation operation on candidate device pairs includes: 106a. The scheduling host generates a lock payload containing the occupant identifier, unique device pair identifier, project model, device number, host information, process number, CI and CD context, and acquisition time, and serializes it into a JSON-formatted temporary file. Here, CI stands for Continuous Integration and CD stands for Continuous Delivery. 106b. The JSON-formatted temporary file is pushed to the preset remote lock path of the AI ​​glasses via ADB to form a device-side lock file. 106c. The ADB query command is called a second time to verify whether the device-side lock file is effective. If the verification fails, the temporary file in the AI ​​glasses is deleted and the current candidate device pair is abandoned. 106d. If the verification passes, the host-side occupancy flag in the configuration file is set to occupancy, and the lock payload information is written to the occupancy metadata. The configuration file is updated using a temporary file atomic replacement method. 106e. If the configuration file update fails, the device-side lock file in the AI ​​glasses is deleted synchronously to complete the rollback. If the update is successful, the host-side cross-process file lock is released, and a device lease containing device pair information, lock file path, and occupancy information is returned to the test task. The occupancy metadata stores at least the occupant identifier, device pair unique identifier, device number, lock file path, acquisition time, and recovery audit field, which are used for problem tracing and status auditing.

[0027] Step 107: If all candidate device pairs fail to be allocated, the scheduling host releases the host-side cross-process file lock and goes to sleep, waiting for the polling interval before re-executing the allocation process. If allocation fails within the timeout period, a timeout exception is thrown. The scheduling host provides an HTTP interface that encapsulates device pair allocation, device pair release, lock status query, and consistency recovery functions into interface services for remote CI and CD pipelines and automated testing systems to call.

[0028] Please see Figures 1-3 In this embodiment, the allocation and release are performed by the scheduling host. Dual locking refers to the requirement to acquire two locks simultaneously for the same allocation operation. Lock 1: Host-side cross-process file lock, applied to the local configuration directory of the scheduling host; Lock 2: Device-side lock file, which operates in the internal storage directory of the assigned glasses device (example path: / sdcard / .ci_device_pool.lock).

[0029] The allocation is considered effective only if both locks are successfully acquired; if either lock fails, the allocation fails and is rolled back.

[0030] The definition of a device pair: In this invention, a device pair is used as the smallest allocation unit.

[0031] A device pair includes at least: 1. A pair of glasses (fields: glass_device_id, project_type, etc.) carrying the firmware under test; 2. A paired mobile phone (fields: phone_device_id, appium_port, platform, etc.) that carries the accompanying mobile app and is paired with the glasses; 3. Each device has a unique identifier, pair_id; 4. An enable / disable switch; 5. The "host-side occupancy flags" are_busy and busy_meta (where busy_meta records the occupant, acquisition time, device pair, device-side lock file path, etc.). Multiple device pairs are stored in a mapping relationship under the device_pairs field of the configuration file configs / devices.yaml.

[0032] Please see Figures 1-3 After the test task is completed, the scheduling host invokes the device release procedure in the finally semantics. The device release procedure includes the following steps: Step 201: The scheduling host acquires a cross-process file lock on the host side; Step 202: The scheduling host locates the target device pair to be released based on the device pair's unique identifier or device number; Step 203: The scheduling host verifies whether the occupant identifier in the occupant metadata of the target device pair is consistent with the occupant identifier requested for release. If they are inconsistent and the forced release mode is not enabled, the release is refused and an exception is thrown. Step 204: The scheduling host queries the device-side lock file in the AI ​​glasses via ADB. If the lock file exists, a deletion command is issued. If deletion fails and the forced release mode is not enabled, an exception is thrown. Step 205: The scheduling host clears the host-side occupancy flag and occupancy metadata, and updates the configuration file using a temporary file atomic replacement method; Step 206: The scheduling host releases the host-side cross-process file lock and returns the release result to the device.

[0033] Please see Figures 1-3 The lock state consistency recovery process includes the following steps: Step 301: The scheduling host receives a recovery request containing the device's unique identifier, occupant identifier, and remote lock deletion switch parameters; Step 302: The scheduling host acquires the host-side cross-process file lock, re-detects the host-side occupancy flag and the device-side lock file status of the target device pair, and determines the current lock status; Step 303: If the inconsistency is determined, the scheduling host performs repair according to the state combination: if the host side is occupied and the device side is unlocked, the host side occupancy flag and occupancy metadata are cleared; if the host side is not occupied, the device side is locked and the remote lock deletion switch is turned on, the device side lock file in the AI ​​glasses is deleted. Step 304: After the repair is completed, the scheduling host writes the person who performed the recovery operation and the recovery time into the occupied metadata as audit information, releases the cross-process file lock on the host side, and returns the latest status of the device.

[0034] Please see Figures 1-3 In this embodiment, the allocation process is executed by the "device pool management device" on the scheduling host.

[0035] I. Equipment Allocation Process Step 101: The scheduling host receives a test task request, which carries four core parameters: "project type", "owner", "maximum waiting time", and "polling interval".

[0036] Step 102: The scheduling host attempts to acquire a cross-process file lock on the host side. Specifically, the scheduling host attempts to acquire the lock in "non-blocking exclusive" mode using the fcntl.flock system call on Linux / macOS platforms or the msvcrt.locking runtime library call on Windows platforms in the configs / .device_pool.lock file in the project root directory. If the lock acquisition fails, it retryes at the polling interval until a hit or timeout occurs; if a hit occurs, proceed to step 103.

[0037] Step 103: While holding the file lock on the host side, the scheduling host reads configs / devices.yaml and iterates through all device pairs under device_pairs that are enabled (enabled is true) and whose project_type matches the requested value.

[0038] Step 104: For each candidate device pair, the scheduling host sends a message in the form of adb -s to the glasses device of that device pair via ADB.<glass_device_id> The shell command "if [-f<remote lock path>]; then echo __LOCK_EXISTS__; else echo __LOCK_MISSING__; fi" is used to determine whether the device-side lock file exists, and three return values ​​are obtained: exists, does not exist, ADB does not respond, or outputs an error.

[0039] Step 105: The scheduling host combines the two-dimensional information of "host-side is_busy flag" and "device-side lock file existence" to calculate the current status of the device pair: if both are "no", it is determined to be "idle"; if both are "yes", it is determined to be "busy"; if the host side is "no" but the device side is "yes", or if the host side is "yes" but the device side is "no", it is determined to be "inconsistent"; if ADB does not respond or returns an exception, it is determined to be "unknown".

[0040] Step 106: The scheduling host only initiates the allocation process for device pairs determined to be "idle". The allocation process is as follows: Step 106a: The scheduling host generates a lock payload, which includes at least the following: owner, pair_id, project_type, glass_device_id, phone_device_id, hostname of the scheduling host, process ID of the scheduling host, CI and CD context fields (such as JOB_NAME, BUILD_NUMBER, BUILD_TAG), and acquisition time.

[0041] Step 106b: The scheduling host serializes the payload into JSON format and temporarily stores it as a local temporary file.

[0042] Step 106c, the scheduling host uses adb -s<glass_device_id> The `push <local temporary file> <remote lock path>` command pushes the lock file to the internal storage directory of the glasses device (e.g., ` / sdcard / .ci_device_pool.lock`). After a successful push, the scheduling host verifies the existence of the device-side lock file a second time using the same shell command as in step 104. If the verification passes, the device-side lock file is considered effective; if the second verification fails, the scheduling host executes a delete command on the device-side lock file to roll back the process and abandons the candidate device pair for this round.

[0043] In step 106d, after the device-side lock file verification is successful, the scheduling host sets the is_busy flag on the host side to true and writes busy_meta to fields such as owner, pair_id, project_type, device identifier, device-side lock file path, and acquisition time. The writing process uses a "temporary file + atomic replacement" method (tempfile.NamedTemporaryFile is written and then os.replace) to ensure the consistency of the configuration file.

[0044] In step 106e, if the write operation on the host side fails, the scheduling host synchronously deletes the device-side lock file to maintain state consistency; if the write operation succeeds, the host-side file lock is released, and a DeviceLease object containing fields such as pair_id, project_type, glass_device_id, phone_device_id, lock_file, owner, and acquired_at is returned to the caller.

[0045] Step 107: If all candidate device pairs are not successfully allocated, the scheduling host releases the host-side file lock for the current round at the poll_interval_seconds polling interval and then sleeps before retrying; until a device pair is obtained within the timeout_seconds duration, or a DevicePoolTimeoutError exception is thrown due to timeout.

[0046] II. After the test execution is completed (regardless of success, failure, or exception), the scheduling host or the test execution process invokes the release procedure in the finally block. The specific steps are as follows: Step 201: The scheduling host acquires the host-side cross-process file lock (mechanism is the same as step 102).

[0047] Step 202: The scheduling host locates the unique device pair based on pair_id or glass_device_id / phone_device_id.

[0048] Step 203: The scheduling host verifies whether busy_meta.owner is consistent with the owner passed in by the caller. If they are inconsistent and force=True is not specified, the release is refused and an exception is thrown to prevent task A from mistakenly releasing the device of task B.

[0049] Step 204: The scheduling host queries the device side lock file for existence via ADB; if it exists, it issues an adb -s command.<glass_device_id> The shell command "rm -f<remote lock path>" is used to delete the lock. If the deletion fails and force=True is not specified, an exception will also be thrown.

[0050] Step 205: After the device-side lock file is processed, the scheduling host sets is_busy on the host side to false, clears busy_meta, and writes it back to configs / devices.yaml again using the "temporary file + atomic replacement" method.

[0051] Step 206: The scheduling host releases the file lock on the host side and returns the release result.

[0052] III. Consistency Recovery Process: The scheduling host provides a consistency recovery interface (e.g., HTTP interface POST / device_pool / recover) to the outside world. The interface is configured according to... Figure 3 The specific steps for execution are as follows: Step 301: The scheduling service process receives a request containing three parameters: pair_id, owner, and remove_remote_lock_when_flag_false.

[0053] Step 302: The scheduling host, while holding the file lock on the host side, recalculates the dual-channel status of the device pair.

[0054] Step 303: When the status is "inconsistent", the following strategy is used to repair it: When the host side is "yes" and the device side is "no", the scheduling host sets the host side is_busy to false and clears busy_meta; when the host side is "no", the device side is "yes" and the request parameter remove_remote_lock_when_flag_false=True, the scheduling host issues a lock file deletion command on the device side.

[0055] Step 304: After the repair is completed, the scheduling host writes the last_recovered_by and last_recovered_at fields into busy_meta as audit clues and returns the latest status.

[0056] IV. Device Composition The device pool management system consists of a "scheduling host" and a "cluster of tested glasses devices".

[0057] 1. The scheduling host side further includes: (1) Cross-process file lock module: The fcntl.flock call is encapsulated on the Linux / macOS platform and the msvcrt.locking call is encapsulated on the Windows platform. It provides __enter__ / __exit__ context semantics to the outside world, with timeout and polling parameters to ensure mutual exclusion between multiple processes.

[0058] (2) Device registration module: Stores all static fields (identifier, project model, glasses device identifier, paired mobile phone identifier, Appium port, Bluetooth address, etc.) and dynamic fields (is_busy flag, busy_meta occupied metadata) of all device_pairs in YAML file.

[0059] (3) Dual-channel status judgment module: jointly reads the is_busy flag on the host side and the existence of the lock file on the device side, and outputs one of the four states: "idle / occupied / inconsistent / unknown".

[0060] (4) Allocation Execution Module: According to steps 101 to 107, the device-side lock file is issued to the device in the "idle" state, secondary verification is performed, the host-side flag bit is atomically written, and the lease object is returned.

[0061] (5) Release execution module: Execute the following steps: delete the device-side lock file, clear the host-side flag, verify the owner and write back atomically.

[0062] (6) Consistency recovery module: Perform automatic identification and controllable recovery of dirty state according to steps 301 to 304.

[0063] (7) Scheduling service process: Expose the capabilities of allocation, release, status query, consistency recovery, etc. to the outside world in the form of HTTP interface (such as / device_pool / status, / device_pool / recover) to facilitate remote testing of scheduling system calls.

[0064] 2. The glasses device only needs to have an internal storage directory (such as / sdcard / ) accessible via ADB. The lock file issued by the scheduling host occupies an agreed path. The device does not need to run any resident services to become the carrier of the lock signal.

[0065] V. Brief Description of Working Principle The scheduling host first serializes all concurrent tasks into the same critical section using cross-process file locks, ensuring that only one task is querying and modifying devices.yaml at any given time. Within the critical section, the scheduling host queries the lock file status from the glasses device entity via ADB and issues the lock file, atomically binding the "logical occupancy on the host side" and the "physical occupancy on the device side" at the moment of successful allocation. The two locks are carried by different storage media (scheduling host file system and glasses device file system), and the task is allowed to continue execution only if both locks are hit simultaneously; if one lock is hit while the other is not, it is considered a dirty state, which is repaired by the consistency recovery module according to the agreed strategy. Thus, this invention maintains the parallel capabilities of multiple devices while simultaneously closing out the problems of "preemption conflicts" and "dirty states" at the allocation entry point.

[0066] VI. Some terms are explained below: ADB, Android Debug Bridge, is a command-line communication tool between a host and an Android device. Pytest is an open-source automated testing framework based on Python. Appium is an open-source mobile terminal automated testing server program. HTTP, Hypertext Transfer Protocol; API, Application Programming Interface; YAML, a human-readable data serialization format, is used in this invention to describe device configurations; JSON, a lightweight data exchange format, is used in this invention to describe the contents of the device-side lock file; Fcntl, a system call module for file locking on Linux / macOS platforms; Msvcrt is a runtime library module for file locking on the Windows platform. CI and CD, continuous integration and continuous delivery.

[0067] As can be seen from the above, compared with the prior art, the present invention has at least the following beneficial effects: 1. Dual-lock mutual exclusion provides strong anti-conflict capabilities. The host-side file lock manages concurrent read and write operations across multiple processes, while the device-side file lock verifies the actual device occupancy status. The failure of a single lock will not cause unauthorized device preemption, thus fundamentally avoiding multi-task conflicts and improving test stability.

[0068] 2. Atomic scheduling of devices avoids resource waste. The AI ​​glasses and paired Android phone are bound together as a whole for allocation and release, eliminating issues such as idle use cases and device idling caused by single-device occupancy, thus optimizing resource scheduling logic.

[0069] 3. Status visualization and automatic recovery reduce operation and maintenance costs. The four-state model accurately identifies four types of states: idle, occupied, inconsistent, and unknown. It is equipped with an automated consistency recovery interface, eliminating the need for manual intervention to handle dirty states. Combined with audit fields, the source of anomalies can be traced.

[0070] 4. Lightweight deployment and wide adaptability. The AI ​​glasses rely solely on lock files for state marking, eliminating the need for persistent services and consuming virtually no device computing power or memory. This allows for rapid adaptation to different AI glasses models.

[0071] 5. Cross-platform compatibility and diverse use cases. The host side supports Linux, macOS, and Windows operating systems, and can be deployed and used on local development machines and public test servers, adapting to different testing environments.

[0072] 6. Deep integration with CI and CD facilitates issue traceability. The occupancy metadata embeds contextual information such as task names and build numbers from CI and CD pipelines, allowing for reverse location of abnormal test tasks based on device occupancy status, thus improving troubleshooting efficiency.

[0073] 7. Multi-project isolated operation. A single scheduling host can manage multiple device pools of different project models simultaneously. The test tasks of each project are isolated from each other and do not interfere with each other, improving the cluster reuse rate.

[0074] The specific embodiments described above are preferred embodiments of the present invention and are not intended to limit the specific scope of the present invention. The scope of the present invention includes, but is not limited to, these specific embodiments. All equivalent changes made in accordance with the present invention are within the protection scope of the present invention.

Claims

1. A dual-lock scheduling method for Android and AI glasses device pools, characterized in that, This method is applied to an automated testing cluster consisting of a scheduling host and multiple device pairs, where each device pair includes one AI glasses and one paired Android phone. The method includes a device pair allocation process, a device pair release process, and a lock state consistency recovery process. The device pair allocation process includes the following steps: Step 101: The scheduling host receives a test task request carrying the project model, occupant identifier, maximum waiting time, and polling interval. Step 102: The scheduling host attempts to acquire a cross-process file lock on the host side. If the lock acquisition fails, it will continue to retry according to the polling interval until the lock is successfully acquired or the maximum waiting time is reached. Step 103: While holding the cross-process file lock on the host side, the scheduling host reads the preset configuration file and filters out candidate device pairs that are enabled and whose project model matches the test task request. Step 104: For each candidate device pair, the scheduling host sends a query command to the corresponding AI glasses via ADB to detect the existence status of the device side lock file in the internal storage directory of the AI ​​glasses. Here, ADB refers to Android Debug Bridge. Step 105: The scheduling host combines the host-side occupancy flag in the configuration file with the device-side lock file existence status to determine whether the candidate device pair is in one of four states: idle, occupied, inconsistent, or unknown. Step 106: The scheduling host only performs allocation operations on candidate device pairs whose status is idle, synchronously completes the writing of the device-side lock file and the update of the host-side occupancy flag, and releases the host-side cross-process file lock and returns the device lease after successful allocation. Step 107: If all candidate device pairs fail to be allocated, the scheduling host releases the host-side cross-process file lock and goes to sleep, waiting for the polling interval before re-executing the allocation process. If the allocation fails to be successful within the timeout period, a timeout exception is thrown.

2. The dual-lock scheduling method for Android and AI glasses device pools as described in claim 1, characterized in that, After the test task is completed, the scheduling host invokes the device pair release procedure in the finally semantics. The device pair release procedure includes the following steps: Step 201: The scheduling host acquires a cross-process file lock on the host side; Step 202: The scheduling host locates the target device pair to be released based on the device pair's unique identifier or device number; Step 203: The scheduling host verifies whether the occupant identifier in the occupant metadata of the target device pair is consistent with the occupant identifier requested for release. If they are inconsistent and the forced release mode is not enabled, the release is refused and an exception is thrown. Step 204: The scheduling host queries the device-side lock file in the AI ​​glasses via ADB. If the lock file exists, a deletion command is issued. If deletion fails and the forced release mode is not enabled, an exception is thrown. Step 205: The scheduling host clears the host-side occupancy flag and occupancy metadata, and updates the configuration file using a temporary file atomic replacement method; Step 206: The scheduling host releases the host-side cross-process file lock and returns the release result to the device.

3. The dual-lock scheduling method for Android and AI glasses device pools as described in claim 2, characterized in that, The lock state consistency recovery process includes the following steps: Step 301: The scheduling host receives a recovery request containing the device's unique identifier, occupant identifier, and remote lock deletion switch parameters; Step 302: The scheduling host acquires the host-side cross-process file lock, re-detects the host-side occupancy flag and the device-side lock file status of the target device pair, and determines the current lock status; Step 303: If the inconsistency is determined, the scheduling host performs repair according to the state combination: if the host side is occupied and the device side is unlocked, the host side occupancy flag and occupancy metadata are cleared; if the host side is not occupied, the device side is locked and the remote lock deletion switch is turned on, the device side lock file in the AI ​​glasses is deleted. Step 304: After the repair is completed, the scheduling host writes the person who performed the recovery operation and the recovery time into the occupied metadata as audit information, releases the cross-process file lock on the host side, and returns the latest status of the device.

4. The dual-lock scheduling method for Android and AI glasses device pools as described in claim 3, characterized in that: In step 102, the host-side cross-process file lock is implemented based on the system interface. The Linux / macOS platform uses the fcntl.flock system call, and the Windows platform uses the msvcrt.locking runtime library call to perform the locking operation in non-blocking exclusive mode.

5. The dual-lock scheduling method for Android and AI glasses device pools as described in claim 4, characterized in that: In step 105, the specific rules for determining the four states are as follows: if the host-side occupancy flag is not occupied and the device-side lock file does not exist, it is determined to be idle; if the host-side occupancy flag is occupied and the device-side lock file exists, it is determined to be occupied; if the host-side occupancy flag and the device-side lock file state do not match, it is determined to be inconsistent; if the ADB command does not respond or returns an exception, it is determined to be unknown.

6. The dual-lock scheduling method for Android and AI glasses device pools as described in claim 5, characterized in that, In step 106, the scheduling host performs an allocation operation on the candidate device pair, specifically including: 106a, the scheduling host generates a lock payload containing the occupant identifier, unique device pair identifier, project model, device number, host information, process number, CI and CD context, and acquisition time, and serializes it into a JSON format temporary file, where CI is Continuous Integration and CD is Continuous Delivery; 106b, the JSON format temporary file is pushed to the preset remote lock path of the AI ​​glasses via ADB to form a device-side lock file; 106c, the ADB query command is called a second time to verify whether the device-side lock file is effective. If the verification fails, the temporary file in the AI ​​glasses is deleted and the current candidate device pair is abandoned; 106d, after the verification passes, the host-side occupancy flag in the configuration file is set to occupancy, and the lock payload information is written to the occupancy metadata. The configuration file is updated using a temporary file atomic replacement method; 106e, if the configuration file update fails, the device-side lock file in the AI ​​glasses is deleted synchronously to complete the rollback. If the update is successful, the host-side cross-process file lock is released, and a device lease containing device pair information, lock file path, and occupancy information is returned to the test task.

7. The dual-lock scheduling method for Android and AI glasses device pools as described in claim 6, characterized in that: In step 103, the configuration file is a YAML format file that uniformly stores the static and dynamic information of all device pairs. The static information includes the unique identifier of the device pair, the AI ​​glasses number, the Android phone number, the Appium port, and the project model. The dynamic information includes the host-side occupancy flag and occupancy metadata.

8. The dual-lock scheduling method for Android and AI glasses device pools as described in claim 7, characterized in that: In step 104, the AI ​​glasses only reserve a preset internal storage directory to store the device lock file. There is no need to deploy a resident service. The reading, writing and deletion operations of the device lock file are all executed remotely by the scheduling host through ADB commands.

9. The dual-lock scheduling method for Android and AI glasses device pools as described in claim 8, characterized in that: The scheduling host provides an HTTP interface to the outside world, which encapsulates the functions of device pair allocation, device pair release, lock status query, and consistency recovery into interface services for remote CI and CD pipelines and automated testing systems to call.

10. The dual-lock scheduling method for Android and AI glasses device pools as described in claim 9, characterized in that: The occupancy metadata stores at least the occupant identifier, device pair unique identifier, device number, lock file path, acquisition time, and recovery audit field, which are used for problem tracing and status auditing.

Images