User Guide

1 Operating a Video Stream Cloud Phone Instance

1.1 Starting a Video Stream Cloud Phone Instance

You can set parameters in the cfct_config file to start video stream cloud phone instances with different resolution and frame rates, and set the initial video encoding parameters in the default.prop file. If WebRTC is used for data transmission, you can modify the default.prop file to change the snapshot resolution; if you use an APK to access the video stream cloud phone, you can configure the snapshot resolution in the APK settings.

1. (Optional) To start video stream cloud phone instances with custom frame rates, modify the frame rate property in the cfct_config file. The default frame rate is 30 fps. 60 fps is also supported when the resolution is 720p or 1080p.

   BUILD_FPS=30

2. (Optional) To start video stream cloud phone instances with the C2 decoder enabled (applicable to configuration scheme 1), configure ENABLE_AMD_C2_DECODE=1 in the cfct_config file. 0 (default) and any other values indicate disabled. The C2 decoder needs to be enabled or disabled during the initial container startup; dynamic switching is not supported. Built-in cloud phone applications will automatically select the appropriate decoder based on their specific requirements.

   ENABLE_AMD_C2_DECODE=0

3. To start video stream cloud phone instances with different initial encoding parameters, snapshot resolution, and audio and video output formats over WebRTC, perform the following operations:

   1. Decompress DemoVideoEngine.tar.gz to obtain the vendor folder and copy the default.prop file in the folder to the current directory.

      cd /home/kbox_video/
      tar -xvf DemoVideoEngine.tar.gz vendor
      cp vendor/default.prop .

   2. Set initial encoding parameters by configuring property fields started with vmi.video.encode in default.prop. For details about the property fields, see Configuration Items in the Startup Script.

   3. Set the snapshot resolution.

      Configure property fields started with vmi.video.frame in default.prop. For details about the property fields, see Configuration Items in the Startup Script. After changing the resolution, you are advised to change the screen pixel density in the cfct_config file as well to achieve the optimal display effect. Table 1 lists the recommended configurations.

      Table 1 Recommended configurations for different resolutions

      Screen Width (BUILD_WIDTH)	Screen Density (BUILD_DENSITY)
      360	120
      480	160
      720	320
      1080	480
      1440	640
      2160	960

      After you change the video output resolution (to a resolution different from the configuration at the last startup), the rendering resolution of the AOSP system and apps is changed. In this case, a compatibility issue or rendering problem may occur in some apps. Generally, this problem can be solved by restarting apps. It is recommended that you return to the home screen and clear background apps before changing the resolution.

   4. Set the audio and video output formats.

      • If you access a video stream cloud phone instance over WebRTC, configure property fields in default.prop within the allowed value range to set video and audio output formats. For details, see Configuration Items in the Startup Script.
      • If you access a video stream cloud phone instance using an APK, configure property fields in default.prop to set video and audio output formats. For details, see Configuration Items in the Startup Script.

   5. Enable the adaptive resolution function.

      If you access the video stream cloud phone instance using an APK, you can enable the adaptive resolution function on the APK settings page. For details, see Using an APK. If adaptive resolution is disabled, configure property fields started with vmi.video.frame in default.prop to change the snapshot resolution. For details about the property fields, see Configuration Items in the Startup Script. After changing the resolution, you are advised to change the screen pixel density in the cfct_config file as well to achieve the optimal display effect. Table 1 lists the recommended configurations.

   6. If you use the WebRTC method, configure the IP address and the start UDP port.

      In default.prop, configure property fields vmi.webrtc.connection.serverip (IP address of the cloud phone server) and vmi.webrtc.connection.udpbeginport (available UDP start port). For details, see Configuration Items in the Startup Script.

4. Start a video stream cloud phone.

   cd /home/kbox_video/
   ./cfct_video start ${index1} ${index2}

   In the preceding command, ${index1} and ${index2} indicate instance indexes, and ${index2} can be left blank. The following are examples of using the startup script:

   • Start a video stream cloud phone whose index is 1.

     ./cfct_video start 1

   • Start five video stream cloud phones indexed from 1 to 5.

     ./cfct_video start 1 5

   When using NFS for mounting, replace the start command with nstart. For example:

   ./cfct_video nstart 1 5

5. Query video stream cloud phones.

   • Video stream cloud phone with Docker:

     docker ps -a

     Example command output:

     

   • Video stream cloud phone with containerd:

     nerdctl ps -a

     Example command output:

     

   Make sure that the started container can be found and is in normal state.

6. Check whether the video stream cloud phone is successfully started. ${index} indicates the index of the instance to be started. For example, in the last column in the command output of 5, the ${index} of android_35 is 35.

   • Video stream cloud phone with Docker:

     docker exec -it android_${index} sh 

   • Video stream cloud phone with containerd:

     nerdctl exec -it android_${index} sh

     getprop sys.boot_completed

   If the value of sys.boot_completed in the output is 1, the startup is successful.

   

1.2 Querying Component Version Information

This section provides the following two methods to obtain the version of the video stream engine component.

Method 1: using the obtained software package

1. Refer to Software requirements for deploying the video stream engine to obtain BoostKit-boostcph-videoengine_*.zip and decompress it to obtain the version file.

2. Check the version of the video stream engine component.

   unzip BoostKit-boostcph-videoengine_*.zip
   tar -xvf  VideoEngine.tar.gz vendor/etc/videoengine_version.txt
   cat vendor/etc/videoengine_version.txt

   The command output is the version information of the video stream engine component. An example is as follows:

   Product Name: Kunpeng BoostKit
   Product Version: 26.0.RC1
   Component Name: BoostKit-boostcph-videoengine
   Component Version: 8.0.RC1
   Component AppendInfo: 11.0.0_r48

Method 2: calling an external API of the video stream engine

Call the GetVersion API to obtain the version information. For details, refer to "External APIs > Function APIs > GetVersion" in Video Stream Engine Developer Guide. The command output example is the same as that in method 1.

1.3 Accessing a Video Stream Cloud Phone

1.3.1 Using an APK

If the video stream cloud phone is started in the default mode, you can access the cloud phone using an APK.

1. Decompress CloudPhoneApk.tar.gz.

2. Install CloudPhone.apk on an Android phone.

3. (Optional) Tap the gear icon in the upper right corner to access the settings screen.

4. (Optional) Enable the adaptive resolution function. This function is enabled by default. If adaptive resolution is disabled, you need to modify the rendering resolution in default.prop. For details, see step 2 in Starting a Video Stream Cloud Phone Instance.

5. Return to the home page, enter the server IP address and port in top-down order, and tap Connect to access the video stream cloud phone.

   The default port is 8000 + ${index}.

   • A port must be configured for each video stream cloud phone instance. This can be set in the cfct_video script during deployment. The port number ranges from 1024 to 65535 and cannot be an occupied port to avoid port contention and video stream cloud phone access failure.
   • The video stream engine client is 64-bit and must run on 64-bit Android mobile phones running HarmonyOS or Android 7 or later.
   • Ensure that the network connection between the mobile phone and the server is normal.

1.3.2 From a Web Page on a PC

If the video stream cloud phone instance is started with the WebRTC feature enabled for data transmission, you can access the cloud phone from a web page on the PC.

1. Decompress WebClient.zip.

2. Open html/login.html. The following page is displayed.

   

3. Enter the server IP address and port in top-down order, and click SUBMIT to access the video stream cloud phone. The default port is 8000 + ${index}.

   A mapping port must be configured for each video stream cloud phone instance. This can be set in the cfct_video script during deployment. The port number ranges from 1024 to 65535 and cannot be an occupied port to avoid port contention and video stream cloud phone access failure.

1.4 (Optional) Dynamically Modifying Cloud Phone Parameters

You can use CloudPhone.apk to dynamically modify the video and audio encoding parameters when the cloud phone is running.

1. Before connecting to the cloud phone, go to the settings page to confirm that adaptive resolution is enabled by default.

2. After connecting to the cloud phone, tap the gear icon on the screen.

3. Set video encoding parameters.

   1. Tap the video icon.

   2. Set the video encoding parameters.

      For details about the value range of each parameter, see the properties starting with vmi.video.encode in Configuration Items in the Startup Script. The rendering resolution can be 360p, 720p, or 1080p.

   3. After the setting is complete, tap Send to send the parameter values to the server. If the values are valid, they take effect immediately.

      If adaptive resolution is disabled, you can run the setprop command in the container after starting the cloud phone to change property settings. For details about the property fields, see Configuration Items in the Startup Script. To change the width and height of the adaptive resolution, you are advised to change the screen pixel density in the cfct_config file as well to achieve the optimal display effect. Table 1 Recommended configurations lists the recommended configurations for different resolutions.

4. Set audio encoding parameters.

   1. Tap the audio icon.

   2. Set the audio encoding parameters.

      For details about the value range of each parameter, see the properties starting with vmi.audio.encode in Configuration Items in the Startup Script.

   3. After the setting is complete, tap Send to send the parameter values to the server. If the values are valid, they take effect immediately.

1.5 Restarting a Video Stream Cloud Phone Instance

Run the cfct_video script to restart a video stream cloud phone instance.

• Restart a video stream cloud phone whose index is ${index1}.

  ./cfct_video restart ${index1}

• Restart video stream cloud phones indexed from ${index1} to ${index2}.

  ./cfct_video restart ${index1} ${index2}

1.6 Deleting a Video Stream Cloud Phone Instance

Run the cfct_video script to delete a video stream cloud phone instance.

• Delete a video stream cloud phone whose index is ${index1}.

  ./cfct_video delete ${index1}

• Delete video stream cloud phones indexed from ${index1} to ${index2}.

  ./cfct_video delete ${index1} ${index2}

./cfct_video ndelete 1 5

2 Operating a Video Stream Cloud Phone Instance in the Kubernetes Cluster

2.1 Starting the DaoCloud Device Plugin

Start the DaoCloud device plugin on the master node. Before starting the plugin, obtain the TAR package of the video stream engine server for obtaining the audio and video data of the Kbox container.

Obtain the DemoVideoEngine.tar.gz software package based on Software requirements for deploying the video stream engine, and upload the software package to the /home/k8s directory on the server.

1. Decompress DemoVideoEngine.tar.gz.

   cd /home/k8s/
   tar -xvf DemoVideoEngine.tar.gz

2. Create a label (va-device=va-sg100) on the specified Kubernetes node.

   kubectl label nodes $NODENAME va-device=va-sg100

   $NODENAME indicates the name of a worker node.

3. Create a namespace va-plugin.

   kubectl create ns va-plugin

4. Create a ConfigMap object va-plugin and add the content of the config.yaml file to the ConfigMap.

   cd /home/k8s/k8s/script
   kubectl create cm -n va-plugin va-plugin-configs --from-file=config=config.yaml

5. Change the name of the DaoCloud device plugin image.

   vi va-device-plugin.yaml

   Change the value of the following field to the actual value:

   spec.spec.containers.image: Enter the name of the DaoCloud device plugin image imported to the worker node.

6. Start the DaoCloud device plugin.

   cd /home/k8s/k8s/script
   kubectl create -f va-device-plugin.yaml

   You can run the kubectl delete -f va-device-plugin.yaml command to delete the DaoCloud device plugin.

7. After the startup is complete, check whether the DaoCloud device plugin can run properly.

   kubectl get pods -A

   It is expected that the Pod names should start with va-device-plugin-daemonset and their status in the STATUS column should all be Running.

2.2 Starting the Device Plugin

Start the device plugin on the master node.

1. Start the device plugin.

   cd /home/k8s/k8s/script
   ./start_devices.sh

   You can run the ./delete_devices.sh command to delete the device plugin.

2. After the startup is complete, check whether the device plugin can run properly.

   kubectl get pods -A

   It is expected that the STATUS column of Pods whose names start with k8s-host-device is Running.

2.3 Running the Hook Script

Run the hook script on all worker nodes.

1. Obtain DemoVideoEngine.tar.gz based on Video Stream Engine Installation Guide and upload it to the /home/k8s directory on the server.

2. Copy the oci-device-hook.sh script in the /home/k8s/k8s/script directory to the /usr/local/sbin/ directory.

   cd /home/k8s/k8s/script
   cp oci-device-hook.sh /usr/local/sbin/

3. Modify the containerd configuration by changing the container runtime added in Deploying the DaoCloud Device Plugin Image to /usr/local/sbin/oci-device-hook.sh.

   sed -i 's|BinaryName = "/usr/bin/va-container-runtime"|BinaryName ="/usr/local/sbin/oci-device-hook.sh"|g' /etc/containerd/config.toml

4. Restart containerd.

   systemctl restart containerd

2.4 Running the NRI Plugin

Run the NRI plugin on all worker nodes.

1. Obtain DemoVideoEngine.tar.gz based on Video Stream Engine Installation Guide and upload it to the /home/k8s directory on the server.

2. Go to the /home/k8s/k8s/scripts/nri-quota-plugin directory and build the plugin.

   go build -o quota-plugin main.go

3. Configure containerd and restart it to enable NRI.

   Set disable to false in the /etc/containerd/config.toml file.

   [plugins."io.containerd.nri.v1.nri"]
   disable = false
   plugin_config_path = "/etc/nri"
   plugin_socket_path = "/var/run/nri"

   Restart containerd.

   systemctl restart containerd

4. Deploy the plugin.

   mkdir -p /var/log/nri /var/run/nri
   cp quota-plugin /opt/nri-quota-plugin/
   chmod +x /opt/nri-quota-plugin/quota-plugin

5. Start the NRI plugin.

   cp quota-plugin.service /etc/systemd/system/quota-plugin.service
   systemctl daemon-reload
   systemctl enable quota-plugin
   systemctl start quota-plugin

2.5 Starting a Kubernetes Video Stream Cloud Phone Instance

Perform the following operations on worker nodes.

1. Modify the k8s-video.yaml file.

   cd /home/k8s/k8s/script
   vi k8s-video.yaml

   Change the following fields to the actual values:

   • spec.containers.image: video stream image. Enter the name of the video stream image imported to the worker node.
   • spec.containers.resources.limits.cpu and spec.containers.resources.requests.cpu: number of cores to be bound to containers. The two fields need to be modified together.
   • spec.containers.resources.limits.memory and spec.containers.resources.requests.memory: container memory. The two fields need to be modified together.

2. Start a Kubernetes video stream cloud phone.

   Note: If the created data volume is in f2fs format, the f2fs switch must be configured to 1. If the created data volume is in ext4 format, the f2fs switch must be configured to 0.

   ./k8s-video.sh start ${index1} ${index2} ${index3} ${index4}

   To use NFS for mounting, change start to nstart. Example:

   ./k8s-video.sh nstart ${index1} ${index2} ${index3} ${index4}

   In the command, ${index1} and ${index2} indicate the Pod indexes, and ${index3} indicates whether to enable the f2fs file format. If you enter 0 or leave it blank, the f2fs file format is disabled. The default value is 0. ${index4} indicates the size allocated to the /system partition inside the container, in MB. Entering a value greater than 0 enables it, while entering 0 or leaving it blank disables it. This configuration defaults to 0. ${index2}, ${index3}, and ${index4} can be left blank. Example:

   • Create a Pod named video2 with the default ext4 file format.

   ./k8s-video.sh start 2

   • Create a Pod named video3 with the f2fs file format.

   ./k8s-video.sh start 3 3 1

   • Create a Pod named video3 with the f2fs file format.

   ./k8s-video.sh start 3 3 1

   • Create a total of 5 Pods named video1 to video5 with the default ext4 file format.

   ./k8s-video.sh start 1 5

   • Create a total of 5 Pods named video2 to video6 with the default f2fs file format.

   ./k8s-video.sh start 2 6 1

   • Create a Pod named video1 with the default ext4 file format and a system partition size limit of 10240 MB.

   ./k8s-video.sh start 1 1 0 10240

   • Create a Pod named video2 with the f2fs file format and a system partition size limit of 10240 MB.

   ./k8s-video.sh start 2 2 1 10240

3. Check whether the Pods are successfully started.

   kubectl get pods -o wide

   It is expected that the STATUS column of Pods whose names start with video is Running.

4. Connect to the video stream cloud phone and container. In the NODE column, you can view the node corresponding to the Pod of the video stream cloud phone.

   kubectl get pods -o wide

   Access the video stream cloud phone based on Accessing a Video Stream Cloud Phone. The client connection port is 8000 + ${index}, where ${index} indicates the Pod ID.

   • On any node, run the following command to access the container. The following uses video1 as an example:

     kubectl exec -it video1 -- sh

   • On the worker node, run the crictl ps command to view the cloud phone instance. The corresponding Pod is displayed in the NAME field. Run the following command to access the container. Replace ${CONTAINER} with the value in the first column in the crictl ps command output.

     crictl exec -it ${CONTAINER} sh

2.6 Deleting a Kubernetes Video Stream Cloud Phone Instance

Run the following commands on worker nodes:

cd /home/k8s/k8s/script
./k8s-video.sh delete ${index1} ${index2}

./k8s-video.sh delete 2 (Delete the Pod named video2.)
./k8s-video.sh delete 1 5 (Delete five Pods from video1 to video5.)

./k8s-video.sh ndelete 1 5 (Delete five Pods from video1 to video5.)

2.7 Creating a Base Data Volume

This section demonstrates how to create a base data volume for setting storage isolation and size of a container on a worker node.

1. On the worker node, run the k8s-video.sh script to start a cloud phone. The following uses video1 as an example:

   ./k8s-video.sh start 1

2. On the master node, find the node where video1 resides.

   kubectl get pod -A -owide

   In the command output, find the row where NAME is video1. The value in the NODE column is the node where video1 resides.

3. Pre-install required applications (such as Subway Surfers) in the cloud phone container.

4. Log in to the node where video1 resides. The base data volume is stored in /home/mount/img/video1.img. Rename the image file videobase.img and copy it to the /home/mount/img directory on each worker node. If you want to use videobase.img as the data volume, perform operations based on worker node operation 1.

3 Functional Specifications of Configuration Items

3.1 Commercial Modules of the Video Stream Engine

3.1.1 System Properties

You can configure video, audio, network functions of the video stream engine server using system properties. This section describes how to configure related properties.

Table 1 shows the system properties of commercial modules of the video stream engine. You can change property settings to configure the default commercial module running parameters.

Table 1 Property fields of commercial modules

3.1.2 Configuration Items of the Graphics Acceleration Layer

The graphics acceleration layer supports two configurable functions: GPU mock and shader cache. This section describes the configuration items and rules of the two functions, and provides configuration examples for reference.

• GPU mock: emulates the GPU vendor, GPU model, OpenGL ES version, GL_MAX capability value, and OpenGL ES extension.
• Shader cache: pre-builds shader binaries and shares cache across multiple cloud phones to cut shader compilation and linking time, thereby reducing the stuttering of large OpenGL ES applications.

You can configure the functions in the kbox_render_accelerating_configuration.xml file.

Configuration Items

Table 1 Configuration items in kbox_render_accelerating_configuration.xml

Table 2 Internal parameters of each name property value

Configuration Rules

• Both general system settings and application-specific settings are supported. The application name of general system settings is fixed to system. Application-specific settings can override general system settings. Only the GPU mock function is supported in general system settings.
• GPU mock serves as the fundamental function of other graphics acceleration layer functions. Enabling the shader cache function for an application will automatically enable GPU mock as well.

Configuration Example

<!-- Configuration Example -->
<!-- General system settings -->
<Application name="system" isEnable="false">
     <feature name="kbox.render.accelerating.gpuMock"  isEnable="false">
          <GL_RENDERER_MOCK>
               <param name="GL_RENDERER" value="Mali_G76"/>
               <param name="GL_VENDOR" value="Huawei"/>
               <param name="GL_VERSION" value="OpenGL ES 3.2 Mesa 22.1.7"/>
          </GL_RENDERER_MOCK>
     </feature>
</Application>
<!-- Application-specific settings -->
<Application name="process_name" isEnable="false">
     <feature name="kbox.render.accelerating.shaderCache"  isEnable="false">
          <GL_SHADER_CACHE>
               <param name="SHADER_CACHE_MODE" value="0"/>
               <param name="SHADER_CACHE_DIR_SIZE" value="200"/>
          </GL_SHADER_CACHE>
     </feature>
     <feature name="kbox.render.accelerating.gpuMock"  isEnable="false">
          <GL_RENDERER_MOCK>
               <param name="GL_RENDERER" value="Mali_G76"/>
               <param name="GL_VENDOR" value="Huawei"/>
               <param name="GL_VERSION" value="OpenGL ES 3.2 Mesa 22.1.7"/>
          </GL_RENDERER_MOCK>
          <GL_EXTENSION_MOCK>
               <param name="GL_EXT_blend_minmax" value="1"/>
          </GL_EXTENSION_MOCK>
          <GL_MAX_VALUE_MOCK>
               <param name="GL_MAX_VERTEX_ATTRIBS" value="16"/>
          </GL_MAX_VALUE_MOCK>
     </feature>
</Application>

3.2 Non-commercial Modules of the Video Stream Engine

3.2.1 Configuration Items in the Startup Script

You can configure video stream engine server functions such as hardware decoding and WebRTC by setting configuration items in the startup script cfct_config. This section describes the default configuration items in this file.

Table 1 describes the default configuration items in the video stream startup script cfct_config for non-commercial modules.

Configure the default running parameters for audio and video modules of the video stream engine based on this table.

Configure the default running parameters of the WebRTC module of the video stream engine based on WebRTC Configuration Items.

Table 1 Configuration items in the script

3.2.2 Video Stream Engine Property Configuration Items

This section describes the system properties of non-commercial modules of the video stream engine, such as the video and audio modules. You can change property settings to configure the default running parameters of these modules.

Table 1 describes the system properties of non-commercial modules of the video stream engine.

Table 1 Property fields of the video stream engine

3.2.3 WebRTC Configuration Items

This section describes the system properties of the non-commercial WebRTC module. You can change property settings to configure the default running parameters of this module.

Table 1 describes the system properties of WebRTC.

Table 1 WebRTC property fields

3.2.4 Dynamic CPU Frequency Regulation Within Containers

3.2.4.1 Background

On physical devices, the system dynamically regulates the CPU frequency to balance load and power consumption. In contrast, cloud phones run in a containerized environment relying on the host, where the underlying physical CPU frequency typically remains constant, differing from physical devices. The following steps describe how to implement dynamic CPU frequency regulation for cloud phones to improve emulation fidelity.

3.2.4.2 Procedure

Currently, third-party detection applications typically retrieve the current CPU frequency of a device by reading two files: scaling_cur_freq and cpuinfo_cur_freq. To enhance the emulation fidelity of cloud phone devices, both files need to be modified.

Before making modifications, ensure that you have write permissions for the relevant paths. Run the following commands inside the container to check the permissions for these paths:

ls -ld /sys/devices/system/cpu/cpu${cpu_id}/cpufreq/scaling_cur_freq

ls -ld /sys/devices/system/cpu/cpu${cpu_id}/cpufreq/cpuinfo_cur_freq

If the output contains w (such as -rw-r--r--), the file owner (typically root) possesses write permissions.

If the output does not contain w (for example, the output contains -r--r--r--), the file is read-only. In this case, execute the following commands inside the container to grant write permissions. Run the following command to add write (w) permissions to scaling_cur_freq:

chmod u+w /sys/devices/system/cpu/cpu${cpu_id}/cpufreq/scaling_cur_freq

Run the following command to add write (w) permissions to cpuinfo_cur_freq:

chmod u+w /sys/devices/system/cpu/cpu${cpu_id}/cpufreq/cpuinfo_cur_freq

Then, run the following command inside the container to read the list of supported CPU frequencies:

cat /sys/devices/system/cpu/cpu${cpu_id}/cpufreq/scaling_available_frequencies

Next, run the following two commands inside the container to modify the frequencies. It is recommended that the input frequency values match one of the supported CPU frequencies retrieved in the previous step.

echo ${target_frequency} > /sys/devices/system/cpu/cpu${cpu_id}/cpufreq/scaling_cur_freq

echo ${target_frequency} > /sys/devices/system/cpu/cpu${cpu_id}/cpufreq/cpuinfo_cur_freq

If the container restarts, the previous modifications will become invalid, and the CPU frequency values will restore to defaults.

To achieve dynamic CPU frequency regulation, you can copy and paste the following shell script to any path inside the container and execute it. This allows you to observe dynamic CPU frequency changes in third-party applications (such as "Device Info"). In this script, sleep 1 specifies a 1-second interval between changes, which can be modified as required. The FREQS array stores the potential CPU frequency values, and CPU_ID specifies the index of the CPU to be modified. These three values can be adjusted based on your actual requirements.

CPU_ID=0
FREQS=(554000 860000 956000 1042000 1128000 1224000 1320000 1397000 1512000 1628000 1748000 1858000 1954000)
while true; do
   for FREQ in "${FREQS[@]}"; do
      echo $FREQ > /sys/devices/system/cpu/cpu${CPU_ID}/cpufreq/scaling_cur_freq 2>/dev/null
      echo $FREQ > /sys/devices/system/cpu/cpu${CPU_ID}/cpufreq/cpuinfo_cur_freq 2>/dev/null
      echo "CPU${CPU_ID} frequency dynamically regulated to: $FREQ"
      sleep 1
   done
done

3.2.4.3 Verifying Whether the Configuration Takes Effect

After starting the container, install a third-party application (such as "Device Info") inside the container to check whether the CPU frequency matches the expected value. If it matches, the CPU frequency regulation has successfully taken effect.

4 Troubleshooting

4.1 Overview

4.1.1 Troubleshooting Principles

• Fault analysis, locating, and troubleshooting principles:

  • Restore services as soon as possible.
  • Collect fault data immediately and save the data to mobile storage media or other computers.
  • Before crafting a troubleshooting solution, evaluate the impact to ensure service continuity.
  • If a fault occurs on a third-party hardware device, view the documentation of the device or call the service hotline of the third party for assistance.
  • If a fault cannot be located or rectified according to the manual, contact technical support in a timely manner to minimize the service interruption time.

• Precautions:

  • Strictly comply with operation regulations and industrial safety regulations to ensure personnel and equipment safety.
  • Analyze the fault symptom, identify the cause, and then rectify the fault. If the cause is unknown, do not perform operations to prevent the fault from worsening.
  • Before rectifying a fault, keep all on-site records relevant to the fault and do not delete any data or logs.
  • To ensure customer network security and privacy, obtain the customer's consent and authorization before collecting fault logs.
  • Before making any modifications, back up data manually or using a script.
  • Take electrostatic discharge (ESD) prevention measures, for example, wearing an ESD wrist strap when replacing or maintaining devices.
  • Record original information in detail when any problem occurs during maintenance.
  • All major operations such as restarting processes must be documented. In addition, these operations must be performed by qualified personnel who have confirmed the feasibility of the operations, backed up necessary files, and taken contingency and security measures.
  • When the system recovers, check the system running status to confirm that the fault has been rectified. Write associated troubleshooting reports in a timely manner.
  • Exercise caution when performing risky operations and running risky commands.

• Requirements for maintenance personnel:

  • Have basic knowledge of network devices, OSs, and databases, and be skilled at running common commands for maintenance.
  • Understand the logical structure of the on-site service system, mapping relationship between components and on-site devices, and physical connections between on-site devices.
  • Be familiar with the service processes and system structure and be skilled at operating the software and hardware related to a specific service.
  • Know how to locate and rectify common faults.
  • Be adept with remote access.

4.1.2 Troubleshooting Process

The troubleshooting process consists of the following operations: collecting fault information, diagnosing the fault, locating the fault, and rectifying the fault.

Figure 1 Troubleshooting process

Fault Information Collection

Collect as much fault information as possible to facilitate fault location and rectification, such as Logcat logs in AOSP.

Fault Diagnosis

Determine the type and scope of the fault based on the collected information.

Fault Location

Identify the possible causes of the fault. You need to analyze and compare the possible causes of the fault and determine the root cause.

The commonly used methods for fault location are as follows:

• View client logs, especially the alarms.
• View server logs, especially the alarms.
• View OS logs, especially the alarms.
• Check the resource usage, especially the full load and overload of resources.
• Check operation logs for misoperations.
• View configuration files and check whether configurations are correct.

Fault Rectification

Fault rectification refers to the process of rectifying a fault according to different causes of the fault. This process involves checking and repairing devices, modifying configurations, and restarting processes, containers, and servers.

4.2 Information Collection

4.2.1 Statement

Observe the following principles during information collection:

• Perform maintenance operations only after receiving explicit approval from the customer. Any operation without explicit customer approval is prohibited.
• Do not transfer fault locating data out of the customer's network without the customer's approval.

4.2.2 Basic Information Collection

Collecting Site Information

After a fault occurs, collect site information for technical support and R&D engineers to learn about the site. In addition, provide the phone numbers of onsite engineers to ensure smooth communication.

The following table lists the site information to be collected.

Table 1 Site information to be collected

Collecting Basic Fault Information

Collect basic fault information to learn about the site, current device status, device status before the fault occurred, and possible causes of the fault. For details, see the following table.

Table 2 Basic fault information to be collected

Collecting Fault-related Alarm Information

Collect alarm information related to the fault for further analyzing, locating, and rectifying the fault. For details, see the following table.

Table 3 Alarm information to be collected

Collecting Log Information

Collect system logs and view details about user operations and operation time in the system to analyze and locate the fault.