Overview of Android Signal Processing

First, clarify that the signal discussed in this article is the Linux Soft Interrupt signal, rather than the signal used in the mobile phone status bar to display the current mobile phone communication strength. This article is
The content of an incremental blog is constantly updated. If you are interested in changing the topic, you can occasionally look back at the updated content.

We know that signals in UNIX systems are soft interruptions. Despite its shortcomings (which will be discussed later), it plays an important role in UNIX systems as one of the important asynchronous event processing methods. It can be said that all UNIX systems (including Linux) cannot ignore signal support. Android is essentially a Linux system, and naturally supports signal processing.

However, we also know that a major difference between Android and other Linux systems is that it increases the support of virtual machines (Dalvik VM), and all applications will run in Virtual Machine instances (of course, virtual Machine instances are still running in traditional processes ). To better support application development and debugging, Android adds additional logic for Signal Processing (which will be discussed in detail below ). This also makes the processing behavior of the Android system signal different from that of the traditional Linux system. Many friends may also encounter some confusion when getting started with Android signal processing. Although the answer is a simple answer, it still takes a lot of time to find out the answer.
The purpose of this article is to present all aspects of Android signal processing to everyone. This allows you to learn about Android Signal Processing in the shortest time and apply it to your applications.

Although Android signal processing is not complex, it is difficult to describe it clearly and methodically using an article. Therefore, we will discuss the signal processing in several parts:

1. The overview is this article. Briefly describe the signal processing overview of the Android system and describe the test environment.

2. Signal generation. Discuss the causes of Android signals and the simplest test method.

3. signal processing. This article discusses how the Android system extends traditional signal processing.

4. Application extension. In actual development, we will discuss how to use the android signal mechanism to serve us.

Please first check your understanding of Android signal processing and decide whether you need to pay attention to this series of blog posts. The following are some related questions:

1. What is the difference between Android signal processing and traditional Linux systems (such as UBUNTU?

2. Where does the android signal come from? How can we generate signals in the simplest way and test the signal processing behavior .? How can we analyze problems arising from signal processing as quickly as possible?

3. How Android expands traditional signal processing.

4. What kind of problems can Android Signal Processing Mechanism help us solve during our daily development?

If you can answer all your questions, congratulations. Your understanding of Android signal processing should not be too deep (please leave your contact information and I will ask you for help ). If you cannot answer some questions, this series of articles will help you to supplement this knowledge.

The test environment in this article is:

Simulator: Ubuntu 11.04 runs the latest Android 4.0.1 simulator (for more information, see
Download the source code of android4.0.1 and compile and run the simulator)

Mobile: droid3 with Android 2.3.6

Tablet: xoom2 with Android 3.2

Unless there are behavior differences, all test results will come from the simulator (convenient, haha)

By the way, the defects of the traditional signal processing model mentioned above mainly include the following points:

1. Difficult to expand. This may be due to historical reasons. In early signal processing models, for efficiency and convenience, most of them use integer bit codes to represent a certain signal. The total number is within 32 bits. Most of them have clear meanings, while most of them only provide SIGUSR1 and sigusr2 for users.

2. The behavior in some situations is unreliable. For example, after the same signal reaches continuously, most of them are processed as only one signal. That is to say, you can only know whether the signal has arrived, but not whether it has arrived or not.

For Defect 1, there seems to be no good way (we can't create another signal type ). The feasible method is to reuse the two signals.

For defect 2, if you need to generate the same signal consecutively and process it again, you can add a delay during this period. This is what Android does later.

If you want to discuss or correct my mistakes, leave a message. I will reply as soon as possible, or directly add a discussion on changing the topic in the body. Thank you.