For most embedded systems, particularly for consumer electronics like smartphones, due to their complexity, we must apply some policies to strengthen the stability of the system.
System stability is not only for personal computers and server workstations, but is also critically important for embedded systems. Every smartphone user has faced application non-responsiveness, system hangs, and abnormal restart issues; these fall in the scope of system stability. Some common optimization methods include the following:
Static checkers and analyzers, such as GCC, Sparse, CocciCheck (http://coccinelle.lip6.fr/coccicheck.php), and Smatch (http://smatch.sourceforge.net/)
Peer to Peer Review; an example of a tool for P2P review is Patchwork (http://jk.ozlabs.org/projects/patchwork/)
Suitable internal error handling and error tolerance
A hardware or software watchdog for external error checks with timeout detection
Function testing with enough coverage and batch testing with pressure
Strengthening system stability means fixing the issues mentioned earlier as early as possible and much before the product release stage. System stability is a system feature throughout the development procedure and must be paid more attention.
We'll not discuss all of the methods mentioned previously in detail, but only discuss the part about function testing. To get a stable Linux kernel, we must do a lot of work to test the function of the kernel, device driver, and applications with enough pressure and coverage.
Use the kernel and device drivers as examples; we can test them by writing a set of programs in the shell, and even in the C language. The programs can verify the low-level kernel drivers through the exported sysfs and procfs or debugfs interfaces.
For example, to test the backlight interface of an LCD driver, we write the following piece of shell code:
#!/system/bin/sh # This is a backlight test script bl_path=/sys/class/backlight/bl_xx/brightness for i in $(seq 255 -1 1) do sleep 1 echo $i > $bl_path done
Save it to bl_test.sh, and push it to /system/bin/ in the Android emulator and run it.
$ adb remount $ adb push bl_test.sh /system/bin $ adb shell chmod 777 /system/bin/bl_test.sh $ adb shell /system/bin/bl_test.sh
Then, we can change the brightness value from 255 to 1 automatically with a 1 second interval. Such scripts can be used to perform basic function verification and pressure testing.
System stability in its entirety is a vast topic; it is related to every part of a system, from hardware to software, from the Linux kernel to the Android system and applications.
To improve system stability, the entire project lifecycle must be strictly controlled with standard software QA systems.
Faults should be diagnosed and filtered out during the early requirement analysis, design, and development stages. Delaying them up to the release stage or maintenance stage may cost more resources and even result in financial loss. Errors should be tolerant at runtime.
Test automation is a good method to emulate the using scenes in the release stage. If the test cases are well designed with enough coverage and pressure, most potential issues can be discovered during the testing stage.
Here we would like to introduce a project; that is, the Device driver testing framework for TI OMAP. These test cases for OMAP-specific device drivers are written and maintained in an open Git tree. Refer to http://omappedia.org/wiki/OMAP_Kernel_driver_tests. To use this framework for Android, you only need BusyBox and Bash. Both of them have already been introduced before.
We can port this framework to other platforms and develop our own test cases based on this framework; it is good as practice, and left for readers who want to delve into the topic in depth.
For Android applications, CTS and monkeyrunner are available for compatibility and stability testing.