My Android Notes--my knowledge of the Android system

It's been a long time code, and I'm documenting some of my Android concepts, and most of the content comes from web materials and official documents. The core of the 1,android operating system is a branch of Linux, with typical Linux scheduling and features, and for Linux to run better on mobile devices, Google modifies and expands it, and changes to the Android system we see today. 2, in general, we use the Java programming language to write Android projects, and sometimes we may use jni,c/c++ to accomplish functions that other Android frameworks do not do or for other purposes. For the JNI section, our NDK compiles it into a. So dynamic library file, placed at the specified location in the project, and loaded and invoked in the Java class that is needed. After we have manually completed the processing of the JNI section, the Android SDK packages the Java code we wrote and the other data and resources contained in the project into one. APK (the Android compiler provides a DX tool to convert Java class files to Dex files. Then, by AAPT all the data in the Android project into an. apk file, the file can be installed to run on the Android operating system.     3, for the APK to run we must understand: a,android operating system is a multi-user Linux system, each of which is a different user. b, by default, each app is assigned a unique Linux user ID (the ID is used by the system and cannot be obtained by the app).     The system also sets permissions on all files in the app, so that only the user ID assigned to the app can access the files.     c, each user (process) has its own virtual machine, so the application code runs in an environment that is isolated from other applications. D, by default, each app runs in its own Linux process. Android starts the process when it needs to execute any application components, and then shuts down the process when it is no longer needed or when the system must recover memory for other apps. The virtual machine used by 4,android is a Dalvik virtual machine that uses art virtual machines after 4.4 systems. The difference between art and Dalvik is that when a member is installed, the code in the APK is converted into a machine code to improve the efficiency of the operation, which is more efficient than the Dalvik virtual machine used by the previous JIT.

This is the way Android systems can implement the principle of least privilege . That is, by default, each app has access only to the components that it needs to perform its work, not to other components. This creates a very secure environment in which apps cannot access the parts of the system that they do not have permissions on.

However, apps can still share data with other apps and access system services in some ways: A, you can schedule two apps to share the same Linux user ID, in which case they can access each other's files. To conserve system resources, you can schedule an app with the same user ID to run in the same Linux process and share the same VM (the app must also be signed with the same certificate); B, the app can request access to device data (such as the user's contacts, SMS, Removable storage device [SD card], camera, Bluetooth, etc.) rights Limit.     All app permissions must be granted by the user at installation time. When we first learned about Android programming, the first thing we started to touch was the four components. They are the basic building blocks of Android, each of which is a different hunger point that the system can enter into the application. But not all components are the actual entry points of the user, and each component is independent and plays a different role.

Application components are the basic building blocks for Android apps. Each component is a different point from which the system can enter your application. Not all components are the actual entry points for the user, and some components depend on each other, but each component exists as a separate entity and plays a specific role-each component is a unique building block that helps define the overall behavior of the app.

There are four different types of application components. Each type serves a different purpose and has different lifecycles that define how the components are created and destroyed.

Here are the four types of application components:

Activity ActivityRepresents a single screen with a user interface. For example, an e-mail app might have an activity that displays a list of new e-mail messages, an activity for composing an e-mail message, and an activity for reading e-mail. Although these activity forms a cohesive user experience in e-mail applications through collaboration, each activity is independent of other activity. As a result, other apps can start any of these Activity (if the email app allows it). For example, a camera app can start an Activity within an email app that is used to compose new e-mail messages so that users share pictures. Service Serviceis a component that runs in the background to perform long-running operations or to execute a job for a remote process. The service does not provide a user interface. For example, when a user is in another app, the service may play music in the background or get data over the network, but it does not block the user from interacting with the Activity. Other components, such as Activity, can start a service, let it run, or bind it to interact with it. content providersContent providerManage a shared set of app data. You can store data on the file system, the SQLite database, the Web, or any other persistent storage location that your app can access. Other apps can query the data through the content provider, or even modify the data if allowed by the content provider. For example, an Android system can provide content providers that manage user contact information. Therefore, any application that has the appropriate permissions can query a part of the content provider, such as ContactsContract.Data) to read and write information about a specific person. Content providers also apply to read and write private data that your app does not share. For example, the Notepad sample app uses a content provider to save notes. Broadcast ReceiversA broadcast receiver is a component that responds to system-wide broadcast notifications. Many broadcasts are initiated by the system-for example, the notification screen is turned off, the battery is low, or a photo has been taken for broadcast. Apps can also initiate broadcasts-for example, notifying other apps that some data has been downloaded to the device and available for use. Although broadcast receivers do not display the user interface, they can create status notification bar notifications that alert users when a broadcast event occurs. But the more common use of broadcast receivers is simply as a "channel" to other components designed to perform a very small amount of work. For example, it might initiate a service based on an event to perform a task. Before the Android system launches the application component, the system must verify that the component exists by reading the app's "Androidmainfest.xml" file. Most components must be declared in the manifest file.     In addition to declaring components, manifest files have many other effects: 1, to determine any user rights that the application requires.     2, according to the API used by the application, declare the lowest level of API. 3. Declare the hardware and software features used or required by the app, such as camera, Bluetooth, and multitouch screen 4, declaring API libraries that need to be connected, such as Google Maps API Library 5, other features

My Android Notes--my knowledge of the Android system