Android Document Learning 01_android Basics

• a Once installed on one device, each application survives its own security sandbox
• The system assigns a separate Linux user ID to each application (this ID is only used by the system and is not known to the application)
• the Android system implements the principle of least privilege. By default, each app accesses only the components that need to work, and doesn't do much else. This creates a very secure environment where applications cannot access other parts of the system that are not authorized
• It is possible to schedule two applications to share a Linux system ID, in which case they can access each other's data. To conserve system resources, apps with the same user ID may also be scheduled to run in the same Linux process and share the same VMS (the app must be signed for the same authentication).

• A service is a component that runs long in the background, performs operations, and can even work for remote processes
• the broadcast recipient cannot display the user interface, but when a broadcast event occurs, they can create a status notifier to alert the user. But more of the time, a broadcast receiver is just one other component that wants to do a "gateway" (pathway) for a very small amount of events. For example, It may initiate a service to perform some work on an event.
• any application that launches a component of another application is a unique aspect of Android system design (aspect)
• Unlike most other system applications, Android applications do not have a single point of entry (such as without the main () function).
• your app doesn't have direct access to components in other apps. However, the Android system also activates components for other applications. You must send a message to the system, specify the component you want to start, and then activate the component for you
• three of the 4 components---activities,serivces, and the broadcast receivers----are activated by asynchronous messages called intent. At run time, intents binds a component to other components , regardless of whether the component belongs to your application or another application (you can think of it as a message that asks for an action from another component).
• The content provider is not activated by intents. Further, it is activated by the target requested by the content interpreter (Contentresolver). The content interpreter handles all direct exchanges with the content provider. So the components do not need to be exchanged with the provider, Instead, the Contentresolver object method is called. (This is a bad sentence to understand.) For security reasons, there is an abstraction layer between the component request information and the content provider
• you can broadcast a intent by using Sendbroadcast (), Sendorderedbroadcast (), or Sendstickybroadcast () three methods
• activites,services and content providers, if not declared in manifest, are invisible to the system and will never run. However, the broadcast receiver can be declared in manifest, or it can be created dynamically in code (as a Broadcastreceiver object) and registered with the system through the Registerreceiver () method.
• Use the <supports-screens> element declaration in your manifest file to clearly indicate the screen size your app supports. screen size: small, normal, large and great   screen density: low density density , High density , and very high density
• If your app has to have a special input hardware, you should use the <uses-configuration> element declaration in your app. But when the application has to have a special input configuration, the situation is minimal.
• For example, camera, photosensitive device, Bluetooth, or a version of OpenGL, or touch screen accuracy, you should use the <uses-feature> element to declare the features supported by your app
• You should declare the minimum API level with the <uses-sdk> element, which indicates that those APIs will be used.