Fundamental of Android Framework

In this article, I am covering the basic understanding of android beginner framework development. I have written some other articles about the android framework concepts. To know about these articles, please go through the below profile link:

Budhdi Sharma - Medium

First, briefly introduce the architecture of Android

LINUX KERNEL: Linux core, the Android system is modified based on the Linux system. The bottom layer of Android is Linux, and most of them are some drivers for operating hardware, such as Display Driver, Audio Drivers, and so on.

LIBRARIES: Some libraries written in C language to complete the core functions of Android, such as OpenGL | ES (Simplified Graphic Image Engine), WebKit (browser kernel), SQLite (lightweight database), Surface Manager ), Media Framework (Multimedia Framework), FreeType (font library), SGL (another graphics and image engine), SSL (TCP-based security protocol), libc (fragmented library).

APPLICATION FRAMEWORK: Application framework layer, all written in Java language for developers to call.

APPLICATIONS: Application layer, all the applications we install belong to this layer, such as WeChat, Plants vs. Zombies.

ANDROID RUNTIME: Core Libraries: core library. Dalvik Virtual Machine: Android bottom layer is a Linux system, written in C and C ++ language, so Android program (written in Java language) needs a virtual machine to run on Linux, that is, DVM.

Example: Alarm clock application.

The function of the alarm clock application is actually to play music regularly. The alarm clock application calls MediaPlayer in the APPLICATION and FRAMEWORK layer, and MeidaPlayer accesses the Media and Framework in the LIBRARIES layer, and the Media and Framework uses C language to operate Andio Drivers to play music.

Framework layer

1. Framework function

The framework can actually be simply understood as a storehouse of some APIs. Android developers implement some basic functions and provide them to the upper layer calls through the interface. Repeated calls can be called. The Framework layer is really the layer implemented in the Java language. In this layer, The defined APIs are written in the Java language. But because it contains the JNI method, JNI writes the interface in C / C ++, calls the underlying method in the core library layer according to the function table query, and finally accesses the Linux kernel. Then there are two roles of the Framework layer.

1. Write some standardized modules in Java and encapsulate them into a framework for APP layer developers to call and develop mobile applications with special services.

2. Use the Java Native Interface to call the native method of the core lib layer. The JNI library is loaded when the Dalvik virtual machine is started. Dalvik will directly address this JNI method and then call it.

The combination of the two methods achieves the mutual communication between the Java method and the operating system. Why does Android use Java to write the Framework layer? Isn’t it better to use C or C ++ directly? The relevant experts gave the following explanations:

C / C ++ is too low-level, and developers have to spend a lot of experience to study the language of C / C ++ clearly. For example, the memory mechanism of C / C ++, if you pay little attention, you will forget to open or release it. The Java GC will automatically handle these, saving a lot of time for developers to focus on their business. So it will slowly change from the bottom of C / C ++ to the development language of JAVA, which interacts with the core runtime layer through JNI.

Activity Manager: Used to manage the application life cycle and provide commonly used navigation and rollback functions.

Window Manager: Provides some methods for us to access the mobile phone screen. Screen transparency, brightness, background.

Content Providers: Allows applications to access the data of another application (such as a contact database), or share their own data.

View System: Can be used to build applications. It includes Lists, Grids, Textboxes, Buttons, and even an embedded web browser.

Notification Manager: Allows the application to display customized prompt information in the status bar.

Package Manager: Provides access to system installation packages. Including installing and uninstalling applications, querying permission-related information, and querying Application-related information.

Telephony Manager: It mainly provides a series of methods for accessing the status and information related to mobile phone communication, querying telecommunications network status information, sim card information, etc.

Resource Manager: Provides access to non-code resources, such as local strings, graphics, and layout files (Layout files).

Location Manager: Provides a way to obtain the address and location of the device. Obviously, GPS navigation can definitely use location services.

XMPP: Extensible communication and presentation protocol. Formerly known as Jabber, it provides instant messaging services. For example, push function, Google Talk.

There are many services provided by the Framework layer, so they are not listed one by one.

2. Activity Framework structure and running framework

1. Activity creation will create PhoneWindow, PhoneWindow will create DocerView, and DocerView will create View and ViewGroup.

2. The application adds and deletes windows in the Activity by calling the addView and RemoveView functions of the WindowManager class. The specific implementation is achieved by the WindowManagerImpl implemented in the bridge mode. Then turn to call setView and removeViewLocked of ViewRoot class, and then call addWindow and removeWindow in WMS through IPC mechanism to complete.

3. When AMS (ActivityManagerService) informs ActivityThread to destroy an Activity, ActivityThread will directly call WindowManager’s removeView method to delete the window, implemented in WindowManagerImpl class.

4. AMS calls WMS (WindowManagerService), the general situation is to tell WMS some messages, such as a new Activity to start so that WMS will save a reference to the Activity record, and sometimes will also directly call the WMS interface, such as switching windows When the switch window is started, the setAppStartingWindow of WMS is called directly.

5. WMS internally takes over the processing of input messages and drawing of the screen. The processing of input messages is completed with the help of the InputManager class. The InputManger class generates two threads, InuptReaderThread and InputDispatcherThread. InuptReaderThread reads input messages from EventHub cyclically. Non- big data is distributed through the channel (InputChannel will generate serverChannel and ClientChannel), and the corresponding big data is distributed through the shared cache ShareMemory; InputDispatcherThread will get the message from the Channel or ShareMemory and distribute, the distribution is through InputPublisher, application-layer client Through the InputConsumer, it continuously obtains the distributed messages from Channel or ShareMemory, and then passes them to ViewRoot for processing. InputPublisher, InputPublisher, and InputConsumer are generated by InputMoniter.

So InuptReaderThread and EventHub are producers, InputDispatcherThread is a consumer, InputMoniter is a consumption channel, ViewRoot is a bridge between consumers and producers, and WMS and AMS are family butlers.

3. FrameWork startup process

The Android startup process includes the entire process of loading from the Linux kernel to starting the Home application. The overall process is as follows:

Android is a system platform based on the Linux kernel. When booting, first load the Linux kernel through the bootloader (system loader). When Linux is loaded and started, it is the same as the ordinary Linux startup process. Initialize the kernel first, and then call the init process.

Init process starts zygote: parsing configuration files: init.rc (system configuration file) and initXXX.rc (hardware platform-related files) content to execute a series of commands, including creating mount directory, installing file system, setting properties, starting Attribute server, start Socket service port-”Load preload-classes and preload-resources (Most of the Framework’s classes and resources)-” Fork start a new process Zygote (actually created by fork and execv).

Zygote incubates the first process, SystemServer, which starts various system service threads. The SystemServer process plays the role of a “nerve center” in the Android operating environment. Most of the system services that can be directly interacted with in the APK application are running in this process. Common systems such as WMS, AMS, PackageManagerServer (PmS), etc. Services exist in the SystemServer process as a thread. The main () function of SystemServer first calls the init1 () function, which is a native function, and some initialization work related to the Dalvik virtual machine will be carried out internally. After the function is executed, it will call the init2 () function on the Java side. The function first creates a ServerThread object, which is a thread, and then directly runs the thread. So, from the run () method of ServerThread, the real Start various service threads.

Basically, each service has a corresponding Java class. From the perspective of coding standards, the modes for starting these services can be categorized into three types: Mode 1 refers to the use of a constructor to construct a service because most services correspond A thread, therefore, a thread will be created and run automatically inside the constructor. Mode two refers to the service class that will provide a getInstance () method, through which to obtain the service object, this advantage is to ensure that the system contains only one service object. Mode three refers to the execution from the main () function of the service class. Regardless of the above mode, after the service object is created, sometimes it may be necessary to call the init () or systemReady () function of the service class to complete the startup of the object

After the above service threads are started, AMS calls systemReady to complete the final start, mMainStack.resumeTopActivityLocked (null)-”mService.startHomeActivityLocked starts the first Activity. At this point, the framework started to complete.

We know that any control program has an entry point, and certainly, there is an Android. Check the information to know that the Android framework contains three small partners:

• Server
• client
• Linux driver

In fact, the App we wrote is not a complete program. What we write is just a kit group, which is a bunch of components such as Activity, Service, etc. (everyone must know this). This kit is a complete program for the Framework. Let me first talk about a concept, that is, the EIT model. E is the Engine, I is the Interface, and T is the tire. That is, the engine is connected to the tire through the interface, and then the car can run. Then the frame provides E & I. Generally, the frame provides the engine and the interface. Let’s make the tire, and then install it and run.

An abstract class is to put the engine and interface in a class. Like Activity, it provides an interface function (carnival function) onCreate (). When we write DemoActivity, we must rewrite onCreate (). The abstract class Activity is the engine, onCreate () is the interface, and DemoActivity is the tire. When the framework wants the Activity to run, the onCreate () method is called to drive the operation of DemoActivity. The code we wrote in onCreate () is executed.

Server

The server mainly contains two very important classes: -

• WindowManagerService (WMS).
• ActivityManagerService (AMS).

Client

The client contains the following classes:

• ActivityThread: is the main thread class of Android applications, that is, the UI thread or the main thread. All the work of processing user messages and drawing pages are completed in this thread.
• Activity: ActivityThread will choose which Activity object to put on its boat according to the user’s operation.
• PhoneWindow: Rich second-generation, inherited from the bullish Window class, owns a DecorView object in his house like his father likes to make rules to provide some general window operation API.
• Window: The rich generation, which looks more abstract, likes to make rules, and provides some general window operation APIs. It doesn’t like being managed. So, note: the window managed by WindowManagerService is not the Window class, but it is actually View and ViewGroup.
• DecorView: A very capable guy, the family property comes from FrameLayout, and pays more attention to external dressing. DecorView is a modification of FrameLayout, which can be seen from the name.
• ViewRoot: Little housekeeper. Inherited from Handler, the main function is to convert WMS IPC call to a local asynchronous call.
• Class W: ViewRoot assistant, inherited from the binder, is an internal class of ViewRoot. It mainly helps ViewRoot to convert the WMS IPC call into a local asynchronous call.
• WindowManager: If the client wants to create a window, it must first tell WindowManager, and then it communicates with WindowManagerService to see if it can be created, and the client cannot directly interact with WMS.

Linux driver

The Linux driver and Framework are mainly related to two parts:

• SurfaceFlingger(The painter)
• Binder(The courier)

Each window corresponds to a painted Surface, and SF mainly displays each Surface on the same screen. Binder provides cross-process messaging.

From the running process of the apk program to see when the above components are doing.

ActivityThread starts moving from the main () function and then calls prepareMainLooper () to create a message express channel, MessageQueue, for the UI thread.

Then create ActivityThread object, the creation process will create a message handler Handler object and a courier Binder object, in which Binder is responsible for receiving the remote Ams IPC call, after receiving the call, let Handler load the message to the message express queue, the UI thread is busy It is asynchronous to take messages from the message express queue and perform corresponding operations, such as start, stop, pause.

Then the UI thread allows the queue to call the Looper.loop () method to enter the message loop body. After entering, it will continuously read and process messages from the message queue.

When ActivityThread receives the express delivery of an Activity sent by Ams, it will create the specified Activity object. Activity will first press the window and then press the glass and window grille, so first create PhoneWindow-> DecorView-> create the corresponding View or ViewGroup. After the creation is complete, you can enjoy it, call WindowManager to display the interface on the screen, then create ViewRoot, and then call the remote interface provided by Wms to add a window and display it on the screen.

The next step is the user’s operation. The event thread continuously sends the message to the event queue, and then the secretary of the event distribution thread takes out the messages one by one and then calls the corresponding function in Wms to process the message.

Difference between custom thread and UI thread

The UI thread is run from ActivityThread. In the main () method of this class, Looper.prepareMainLooper () has been used to add a Looper object to this thread. A message queue has been created for this thread, which comes with a secretary halo. Therefore, we can define the Handler object in the Activity, because the thread must have created the message queue when the Handler object is created, and the loading and unloading work must be equipped with the transport belt or the work will not work. The ordinary Thread does not create a message queue by default, so you cannot directly define the Handler directly in the Thread. This is the confusion caused by the fact that we do not understand the principle of program operation.

I have been listening to the user’s voice, and all the work of processing user messages and drawing pages is completed in the UI thread.

The client buddy contains at least three thread brothers. After the Activity starts, it creates a ViewRoot.W object, and ActivityThread creates an ApplicationThread object. These two objects inherit the message manager Binder. Each Binder corresponds to a thread and is responsible for receiving the Linux Binder IPC call sent by the driver. The other is the UI thread.

I hope you enjoyed this session. If you have any comments or questions or suggestions, please join the forum discussion below!

Thanks for the support( follow or Clapp)!!!!!

Android Developers AndroidPIT.com Android Android 1833 Xyz Zyx

The Funtasty Android Devs @Josh Androidservicesme AOSP STUDIO LLC AOSP Extended Android Android 1833