In-depth analysis of the operating mechanism of the Qualcomm platform aee

Preface
This article makes an in-depth research on application execute entironment of Qualcomm platform.
This helps you understand the application scheduling and resource management mechanisms of the entire BREW Platform.
And then develop applications on the Brew platform.
I. Glossary
A) brew: Wireless binary operating environment
B) Applet: a scheduling or execution unit in the aee execution environment
C) task: a task at the operating system level.
D) Rex: Operating System
E) aee: Application Execution Environment
II. Key Technology Analysis
A) at the operating system level, aee does not have independent tasks. It is only a function call attached to ui_task.
Use it;
B) whether an applet is active does not mean whether it can occupy the CPU, but whether it is at the aee level.
Yesactive (can have LCD and keyboard );
C) aee or applet, they are just a set of static code. Therefore, who calls it, it
The context (task level) of the Brew platform.
In the absence of active and deactive, every applet can obtain the execution right (but not necessarily
Run in aee context );
D) Rex is not a time-sharing operating system. Therefore, if a task does not actively release the CPU
Unable to obtain execution right;
E) There are some global components in aee. These components can be implicitly operated through the ishell component. Currently, the most
Importantly, you only need to know That aee maintains a Message Queue internally;
F) messages and Callbacks are essentially the same thing. Send a message to an applet and call one of
Callback functions. The two are essentially the same thing;
Iii. Analysis of aee task scheduling mechanism
When ui_task is appropriate, it will call aee_init () to initialize the aee runtime environment.
When unregistered is stopped, the entire aee runtime environment can be used, and the call of the relevant aee interfaces can work normally. In
Among all the APIs of aee, there is one of the most important functions: aee_dispatch (), that is, aee task scheduling.
Degree function. Calling this function will cause task scheduling within aee. The following is a brief description of aee task scheduling.
Single description.
Each time you need to schedule an aee task, aee only needs to retrieve the frontend from the queue header of its message queue.
According to the specified message receiver in the message body, (classid), call ishell_sendevent (Papp, W, d)
Send the message to the corresponding applet. The operating mechanism of ishell_sendevent is actually very simple.
The handleevent () function of the corresponding applet is used to make an applet run
Permission ". However, at the operating system level, this is just a function call.
The above scheduling mechanism is the core algorithm of aee, which is simple but hard to understand. Next, let's talk about
The role of ishell_postevent. This function is very simple, that is, to directly put messages to the aee Message Queue
Then, during the next aee scheduling, aee retrieves the message and calls the receiving Applet
Event processing functions.
Well, the scheduling algorithm is clear. Is there a problem now? When Will aee_dispatch () be triggered ()
What about it? If this scheduling function is not executed, No scheduling will be available. The key to the problem is that ui_task () will
Aee_dispatch is called (controlled by an aee_app_sig semaphore), while aee_app_sig
Bit, which is regularly sent by a timer of the underlying operating system. From this perspective, the aee will periodically
Task Scheduling at the upper layer.
Iv. instance analysis
The current applet is "running" in the foreground, that is, the display and keyboard control are obtained by the current applet.
If a short message is sent, can the wmsapp get the message and obtain the execution right? If you can
What should I do?
As mentioned above, an applet is just a bunch of static Code. For every applet,
As long as a processing function is called, it is equivalent to "active. From this perspective, assume that
When running wmsapp, it first registers a callback for receiving short messages to the underlying service component (callback: In
Applet implementation, called by the underlying layer), when the underlying service task (here is wms_task) finds a short
When the message comes, it will call the callback function of the wmsapp.
Who is the applet and wmsapp can get the execution right (however, it is executed in the context of ws_task,
In the aee context), you can receive short messages.
Okay. The first problem is fixed. System events can be obtained for any applet, regardless of whether it is active or not.
The key to unregistered is, if it gets a system event and runs it, what should the applet do? For example
Wmsapp, after obtaining a short message event, is the short message interface directly displayed? What should I do?
Remember that only the active applet can have control of the screen and keyboard !! Assume that
In this case, although wmsapp can receive short messages, because it is not an active applet
It cannot control the screen. To gain control of the LCD, it must be changed from "inactive" to "active"
Status. Therefore, after receiving the system message, a non-active applet should
First, you must activate yourself (the practice is very simple, that is, directly call the ishell_startapplet). In this way, it
To operate the LCD and display the corresponding prompt information.
V. aee keyboard distribution and LCD refresh Mechanism
The aee keyboard distribution mechanism is very simple. Every time aee needs to distribute keyboard messages (the keyboard messages will be sent from the bottom
When layer tasks are transferred to aee, you do not need to worry about how to transfer them .)
Single, that is, extract the upper-level applet (that is, the active applet) from its applet stack, and send the Keyboard Message
Send it. That is to say, aee only sends the Keyboard Message to the active applet each time.
Cannot receive keyboard messages.
The LCD refresh mechanism is also simple. Every time the applet calls idisplay_update, The aee
Will make a judgment, if the applet that executes this operation is not an active applet, then aee will not allow it
Update the LCD to achieve the design goal that only the current active applet can operate the LCD.
[Conclusion]
All the applets can receive and process system messages, regardless of whether they are active or not, but only the active applets
You can have a keyboard and LCD.
6. Analysis of various applet states
Logically, an applet has the following states:
A) active (run );
B) Suspend: suspended;
C) Background: Background status;
All the above States are logical concepts. The only difference between the active state and the other two States lies in
In addition, as long as an applet is not close,
They can all obtain various system messages and get the processing right.
The difference between suspend and background is actually quite simple. Applet in suspend state,
If the active applet is disabled, the next suspend applet will automatically become active.
Unregistered: The suspend state applet is still within the automatic scheduling range of aee. The background applet does not
Will automatically become active, unless we manually activate it. To put it bluntly, within aee, the two types of Applet
It must be placed in two different queues. In addition, because the background applet is not automatically activated
So, in many cases, some services use this state of Applet to achieve the best.
How do I switch the status of an applet? Active à suspend is automatic by aee
Complete, that is, each time you start a new applet, the current applet will become suspended and receive the suspend
Message. Once the active applet exits, its next applet changes from suspend state
And receives the resume message. The status switch of active à background is a bit special.
The applet enters the background state and must call the ishell_closeapplet to close the applet. At this time, the Applet
The on_stop message will be received. If it returns true in the message, the applet will actually close
. The key lies in the processing of on_stop messages. Every applet that wants to enter the background status must
Perform the following processing in the message. The simple sample code is as follows:
Case evt_app_stop:
{
Boolean * pb = (Boolean *) dwparam;
If (PB)
{
* Pb = false;/* set the app to background app */
PME-> bsusponded = true;
}
Break;
In this way, an applet enters the background state. If it wants to switch back to the active state, it is very easy,
You can call the ishell_starapplet directly. Please pay attention to the ishell_startapplet (). This code will depend on different applets
Send different messages. For the background applet, it will send an on_start message to the current applet,
For a suspended applet, it sends a resume message to the current applet.
VII. Postscript
The preceding document is a simple analysis of the current aee operating mechanism,
Qualcomm does not publish source code, so it cannot obtain a more accurate analysis result. However, if you can
The above aee operating mechanism has a good understanding, and I believe it will be of great help to develop brew applications in the future.
Finally, thank you for your patience in reading this article. Thank you.
Unregistered