The Android security and privacy model requires permissions to access certain features such as GPS. When clicking the Install button, the user sees the list of permissions and can then make an educated decision to opt out if desired.
Use the permission tag in the application descriptor to list all the permissions needed, as shown in the code below. Permissions cannot be modified at runtime.
Just before installing an application, the Android Market displays the permissions required. Figure 4-1 shows that Queue Manager, an application for managing your Netflix queue, only requires the Internet permission.
<uses-permission android:name=”android.permission.INTERNET” />
To make network requests. Can be used for remote debugging
<uses-permission android:name=”android.permission.WRITE_EXTERNAL_STORAGE” />
To write data to external storage, such as the SDCard
<uses-permission android:name=”android.permission.READ_PHONE_STATE” />
Read-only access of phone state. Used to mute AIR in case of incoming call
<uses-permission android:name=”android.permission.ACCESS_FINE_LOCATION” />
<uses-permission android:name=”android.permission.ACCESS_COARSE_LOCATION” />
Access the location information. Fine for GPS location, Coarse for Cell/Wi-Fi
<uses-permission android:name=”android.permission.CAMERA” />
Access the device camera
<uses-permission android:name=”android.permission.RECORD_AUDIO” />
Access the device microphone
<uses-permission android:name=”android.permission.DISABLE_KEYGUARD” />
<uses-permission android:name=”android.permission.WAKE_LOCK” />
Prevents device from dimming, going in sleep mode and activating keyguard
<uses-permission android:name=”android.permission.ACCESS_NETWORK_STATE” />
Access information on device network interfaces
<uses-permission android:name=”android.permission.ACCESS_WIFI_STATE” />
Access information on device Wi-Fi networks
Android offers a lot of other settings, only some of which can be set in AIR but not documented. They should all be added to the Android→Manifest Additions→Manifest node.
The Android Launcher activity keeps track of the applications that have been launched. If a long press is applied on the home button, a list of recently run applications appears. If you do not want your application to be on this list, add excludeFromRecents to your manifest file as follows:
<android>
<manifestAdditions>
<![CDATA[
<manifest>
<application android:enabled=”true”>
<activity android:excludeFromRecents=”false”>
<intent-filter>
<action android:name=”android.intent.action.MAIN”/>
<category android:name=”android.intent.category.LAUNCHER”/>
</intent-filter></activity>
</application>
</manifest>
]]>
</manifestAdditions>
</android>
Applications are installed on the device memory by default. If you select Settings→ Applications→Manage Applications, you will notice that some applications have the option “Move to SD card” (which then becomes “Move to phone”).
However, some Android applications and AIR applications do not have that option. If you type the following at the command line, all applications will now be moved:
adb shell pm setInstallLocation 2
To restore the settings, type the following:
adb shell pm setInstallLocation 0
If you set the installLocation tag to preferExternal, saving internally is not an option. All of your content, including your application, is stored on the SD card. This could be helpful for large applications. Keep in mind that the content is accessible to other applications, and therefore is vulnerable. If the SD card is full, the system falls back to an installation on the device:
<android>
<manifestAdditions>
<manifest>
<attribute name=”android:installLocation” value=”preferExternal”/>
</manifest>
</manifestAdditions>
</android>
Read the Android recommendation regarding what should not be installed externally, online at http://developer.android.com/guide/appendix/install-location.html.
Users can erase the application data. If you want to prevent them from doing this, you can add the allowClearUserData attribute to the android node:
<manifest>
<application android:allowClearUserData=”false” />
</manifest>
You can also fine-tune permissions to add specific requirements. For instance, you may have an application which only works for devices with a camera auto-focus. You can add a different type of permission, uses-feature, to inform users of what is needed for your application:
<uses-permission android:name=”android.permission.CAMERA” />
<uses-feature android:name=”android.hardware.camera” />
<uses-feature android:name=”android.hardware.camera.autofocus” />
Android throws an error if a required permission is not set, such as for Internet or GPS, but not others, such as reading the phone state or disabling the keyguard. The criterion is what it considered potentially dangerous for the user. In AIR, the application always fails silently.
Native developers have a larger choice of features, and therefore permissions. You can go to http://developer.android.com/reference/android/Manifest.permission.html to learn about some of the new possibilities. If you see one that you would like to use, send Adobe a feature request, preferably with a use case so that it can be added to the AIR runtime, by going to https://www.adobe.com/cfusion/mmform/index.cfm?name=wishform .
For example, having an API to access contacts would open a lot of possibilities:
<uses-permission android:name=”android.permission.READ_CONTACTS” />