For setting attributes that are not commonly used in Android, set attributes in android
Many Attributes in manifest are often forgotten or often seen but not very clear about its role. So here I will take some simple explanations of the attributes to prevent them from being encountered in the future, but I don't know what they mean. Not all. I will try it out in the future.
1. android: installLocation = "internalOnly"
Android: installLocation is affiliated with the manifest node in AndroidManifest. XML:
<manifest xmlns:android="http://schemas.android.com/apk/res/android" package="string" android:sharedUserId="string" android:sharedUserLabel="string resource" android:versionCode="integer" android:versionName="string" android:installLocation=["auto" | "internalOnly" | "preferExternal"] > . . .</manifest>
Android: installLocation can be set to any of the "auto", "internalOnly", and "preferExternal" values.
Auto: The program may be installed on external storage media (for example, SD Card), but it will be installed in the phone memory by default. when the phone memory is empty, the program will be installed on the external storage media. after the program is installed on the mobile phone, you can decide whether to store the program in the external storage media or memory.
InternalOnly: default value. When set to this value, the program can only be installed in the memory. If the memory is empty, the program cannot be installed successfully.
PreferExternal: Installs the program on the external storage media, but the system does not guarantee that the program will be installed on the external storage media. when the external storage media cannot or is empty, the program will be installed in the memory. when the program uses the forward-locking mechanism, it will also be installed into the memory, because external storage does not support this mechanism. after the program is installed, You can freely switch the program on the external or internal storage media.
In short, it is to control whether the application is installed in external storage or memory, and install it in memory.
① Service
The running service will be terminated. When the external storage media is reloaded, the service will not be restarted.
② Alarm Service
The alarm service will be canceled. Developers must re-register the alarm service after the external storage media is reloaded.
③ Input Method Engines
The input method will be replaced with the system input method. After the external storage media is reloaded, you can start our input method through system settings.
④ Live Wallpapers
Our live wallpaper will be replaced with the default live wallpaper. After the external storage medium is reloaded, you can change it back.
⑤ Live Folders
Our dynamic folder will be removed.
⑥ App Widgets
Our widgets will be removed. Normally, our widgets are available only after the system is restarted.
7account Managers
Accounts created using AccountManager will disappear until the storage media is reloaded.
⑧ Sync Adapters
Our synchronization function is available only when the external storage media is reloaded.
Administrative Device Administrators
Our DeviceAdminReceiver will be invalid.
Listen to boot end events
The system will send ACTION_BOOT_COMPLETED broadcast before loading the external storage media. Therefore, programs installed in the external storage media cannot accept the boot broadcast.
Ii. android: versionCode
Google defines two version attributes for APK: VersionCode and VersionName. They have different purposes.
- VersionCode: This code is invisible to consumers. It is used only for the application market, internal program version identification, and new and old application versions.
- VersionName: displays the version to the consumer. The consumer recognizes the version installed by himself.
3. android: protectionLevel = "signature"
Normal: low-risk permission. You only need to apply for the permission (add the <uses-permission> label to AndroidManifest. xml). You do not need to confirm the permission during installation;
Dangerous: high-risk permissions, which must be confirmed by the user during installation;
Signature: only when the digital signature of the application applying for permission is the same as that of the application declaring this permission (if you apply for system permission, the digital signature must be the same as that of the system ), in order to grant the permission to it;
SignatureOrSystem: the application with the same signature or the permission applied for is a system application (in system image ).
The above four permission levels can also be used for custom permissions. If developers need to control the access of their own applications (or some applications. add the <permission> label to xml, and set the protectionLevel in its attribute to one of the above four levels.
Party:
<! -- Declare permissions --> <permission android: name = "com. example. testbutton. RECEIVE"/> <! -- Register the Broadcast Receiver and specify the permissions required to send the message to the current Receiver --> <receiver er android: name = "com. example. testbutton. testButtonReceiver "android: permission =" com. example. testbutton. RECEIVE "> <intent-filter> <action android: name =" com. test. action "/> </intent-filter> </receiver>
Party B:
<! -- Declare to use the specified permission --> <uses-permission android: name = "com. example. testbutton. RECEIVE"/>
Iv. uses-feature
The Android Market filters out all applications not supported by your device based on the uses-feature. By using the <uses-feature> element, an application can specify the Supported Hardware model. For example, some devices do not support multi-touch or OpenGL ES 2.0, then, the filter filters applications that require hardware support (multi-touch or OpenGL ES 2.0) and users will not see these applications on the android market.
Android. hardware. touchscreen. multitouch: it requires the device to have a multi-touch screen to support basic multi-touch interaction, such as shrinking (enlarging) the image ratio. These types of screen tracking have different capabilities for multiple fingers, so you must ensure that the performance of this screen is supported by the game.
Android. hardware. touchscreen. multitouch. distinct: This is a sibling attribute of multi-touch. It requires devices to provide complete multi-touch functions.
Now remember that when your game needs a screen that supports multi-touch, we can use the <uses-feature> element to remove all devices that do not support multi-touch, as shown below:
<uses-feature android:name="android.hardware.touchscreen.multitouch" android:required="true"/>
Another useful feature in game development is to specify the required OpenGL ES version. If your game requires more powerful graphics processing capabilities, we can specify OpenGL ES 2.0, and then our game will only be seen by devices that support OpenGL ES 2.0. Note that OPenGL ES 2.0 is not used in this book. We just filter devices that do not provide sufficient graphic processing capabilities. The following shows how to implement it.
<uses-feature android:glEsVersion="0x00020000" required="true"/>
V. android: supportsRtl = "true"
Android4.2 has a new feature, layoutRtl. Of course, this feature is intended for developers to support reading habits such as Arabic and Persian languages from the right to the left.
You can add android: supportsRtl to the application tag of manifest; set this parameter to true or false.
In this way, you can enable the layoutRtl function. If the current system language is Arabic/Persian, the layout of the application with this function turned on will automatically change from right to left, of course, the premise is that the layout is not written to the location of the control.
6. android: sharedUserId
Android assigns a separate space to each APK process. The userid in manifest is an allocated Linux User ID and creates a sandbox for it, to prevent impact on other applications (or other applications ). The User ID is assigned when the application is installed on the device and remains permanently on the device.
Generally, different apks have different userids, so the runtime is in different processes, and resources in different processes are not shared, ensuring the program running stability. In some cases, if we develop multiple APK files and need to share resources with each other, we need to set the userid to achieve this goal.
With the Shared User id, multiple APK with the same User id can be configured to run in the same process. by default, the system can access any data from each other. you can also configure to run different processes and access the databases and files in the data directory of other APK files. just like accessing the data of this program.
ShareUserId settings:
Add the login userid tag to each AndroidMainfest. xml file of the project to share resources.
Android: sharedUserId = "com. example"
The id is set freely, but the same sharedUserId must be used for each project. One mainfest can only have one consumer userid tag.
<Manifest xmlns: android = "http://schemas.android.com/apk/res/android" package = "com. example. export usertesta "android: versionCode =" 1 "android: versionName =" 1.0 "android: sharedUserId =" com. example ">
\ Data \ custom package \ path mutual access
Each installed program creates a folder in the data \ your package \ of the mobile phone File System Based on its package name (which can be seen only with su permission) for storing Program-related data.
In the Code, when we use context to operate some IO resources, the relevant files are in the corresponding folder in this path. For example, files and databases with external paths are not set by default.
Under normal circumstances, different apk cannot access the corresponding app folder. However, after setting the same consumer userid, you can access each other.
For example, in program
// The default value is data/xxx/file/fOut = openFileOutput ("settings. dat", MODE_PRIVATE );
Osw = new OutputStreamWriter (fOut); osw. write (data); osw. flush ();
Program B
// Obtain context Context ctx = this of program. createPackageContext ("com. example. shareusertesta ", Context. CONTEXT_IGNORE_SECURITY); String msg = ReadSettings (ctxDealFile); Toast. makeText (this, "DealFile2 Settings read" + msg, Toast. LENGTH_SHORT ). show (); WriteSettings (ctx, "deal file2 write ");
The two programs can access each other's resources. (Of course, the premise is that the same consumer userid is set)
Resources and SharedPreferences sharing
Through userid sharing, we can get the context of program. Therefore, we can use context to obtain various resources corresponding to program. It is commonly used to obtain Raw resources. For example, the apk skin package of some software adopts this technology, which divides the main program and the skin resource package into two apk packages.
It is easy to get Resources. After setting the same consumer userid in mainfest of program A and program B, you can get context through createPackageContext. Later, as in the original method, various resources are obtained through the getResources function, but the context environment is the context environment of the target APP.
There are three links between program A and program B:
1. A common userId must be known when declaring the login userId in mainfest.
2 when createpackageContext, you must know the name of the package of the target APK.
3. You need to know the corresponding ID of the resource when obtaining the resource.
VII. android: settingsActivity
I don't know how to use =. This is seen in a source code.
8. android: launchMode = "singleTop" <Activity node>
Activity has the following four launchmodes:
1. standard 2. singleTop 3. singleTask 4. singleInstance
(1) standard: The default standard type of the system. Each jump to the system will generate a new Activity instance in the task and place it on the top of the stack structure. When we press the back key, to see the original Activity instance.
This is the standard startup mode. A new instance is generated no matter whether there are any existing instances. Just like an ordinary stack, it comes out first.
(2) single: It adds an attribute under the standard. That is, when the activity you want to jump to is located at the top of the stack, it will not create a new instance. However, if firstactivity and secondactivity jump alternately, it is the same as the standard mode.
(3) singleTask. The principle is to ensure that the generated activity instance will not be regenerated into a new instance. For example, two activities: first and second. First is set to singleTask, then jump to second, and then return to first, first will not generate an instance, but will retrieve the first from the stack and put it on the top of the stack. Another important point is that the first activity will all be removed from the stack, regardless of whether your activitys are also in singleTask mode.
(4) singleInstance. This is special, but it is also relatively simple. It is to open a new task stack to put this activity, and other activities will not let it in.
9. android: taskAffinity
Each Activity has the taskAffinity attribute, which indicates the Task it wants to enter. If an Activity does not explicitly specify the taskAffinity of the Activity, its attribute is equal to the taskAffinity specified by the Application. If the Application does not, the value of taskAffinity is equal to the package name. Task also has its own affinity attribute. Its value is equal to the taskAffinity value of its root Activity. At the beginning, the created Activity will be in the Task where it is created, and most of the activities have passed its entire life here.
AllowTaskReparenting is used to mark whether the Activity can be moved from the started Task to the Task specified by taskAffinity. By default, it is inherited to allowTaskReparenting = false in the application. If it is true, it can be changed. false indicates no.
These two attributes are usually used together.
In short, when the activity with taskAffinity is instantiated, it will first check whether there are any tasks that are the same as taskAffinity. If there is one, it will run to the task over there and instantiate it.
10. android: configChanges
For android: configChanges attributes, it is generally considered as follows:
1. When the android: configChanges of the Activity is not set, the life cycle of the screen is re-called, the screen is executed once, and the screen is split twice.
2. When setting the Activity's android: configChanges = "orientation", the screen will be switched to call each lifecycle, and the screen will be executed only once
3. When the android: configChanges = "orientation | keyboardHidden" of the Activity is set, the live cycle is not re-called and only the onConfigurationChanged method is executed.
However, since Android 3.2 (API 13), after setting the android: configChanges = "orientation | keyboardHidden" of the Activity, it will call the lifecycle again. The screen size also changes with the switch between devices. Therefore, in AndroidManifest. when the MiniSdkVersion and TargetSdkVersion attributes set in xml are greater than or equal to 13, if you want to prevent the program from re-loading the Activity during runtime, in addition to setting "orientation ", you must also set "ScreenSize ".
Http://www.cnblogs.com/adamzuocy/archive/2009/10/15/1583670.html
11. android: exported
This attribute indicates whether the service can be called or interacted with by other application components. If it is set to true, it can be called or interacted. Otherwise, it cannot. If it is set to false, only components of the same application or applications with the same user ID can start or bind the service. Its default value depends on the filter contained in the service. If no filter exists, the service can only be called by specifying a specific class name, this means that the service can only be used internally in the application (because other external users do not know the class name of the Service). In this case, the default value of this attribute is false. On the other hand, if at least one filter is included, it means that the service can provide services to other external applications, so the default value is true.
This attribute is not the only method that limits the exposure of services to other applications. You can also use permissions to restrict external entities that can interact with the service.
12. android: immersive
It looks like a full screen setting. It can be used to hide the title bar and menu bar. Different UI response events can be implemented through code
XIII. android: excludeFromRecents
The control is not displayed in the recent list, that is, when this activity is used, the app will not appear in the list of recently used apps
==========================================================
Author: cpacm
(Http://www.cnblogs.com/cpacm/p/4083443.html)
What are some common attributes of the button control in android?
<Button
Android: id = "@ + id/loginButton"
Android: layout_width = "50dp
Android: layout_height = "@ dimen/button_footer_height"
Android: layout_alignParentRight = "true"
Android: layout_gravity = "center"
Android: text = "Login"
Android: textSize = "12dp"
Android: visibility = "invisible"/>
I use these
Android attributes
Android: contentDescription = "@ string/app_name"
This is an explanation of your ImageView image. Does this attribute affect the program;
Style = "? Android: attr/buttonStyleSmall "indicates a small button.
Android: minHeight = "20dip" sets the minimum height.
Android: minWidth = "50dip" sets the minimum width.