On Android, as on all computing devices, AIR conforms to
the native security model. At the same time, AIR maintains its own
security rules, which are intended to make it easy for developers
to write secure, Internet-connected applications.
Since AIR applications on Android use the Android package format,
installation falls under the Android security model. The AIR application
installer is not used.
The Android security model has three primary aspects:
-
Permissions
-
Application signatures
-
Application user IDs
Android permissions
Many features of Android
are protected by the operating system permission mechanism. In order
to use a protected feature, the AIR application descriptor must
declare that the application requires the necessary permission.
When a user attempts to install the app, the Android operating system
displays all requested permissions to the user before the installation
proceeds.
Most AIR applications will need to specify Android
permissions in the application descriptor. By default, no permissions
are included. The following permissions are required for protected
Android features exposed through the AIR runtime:
-
ACCESS_COARSE_LOCATION
-
Allows the application to access WIFI and cellular network
location data through the Geolocation class.
-
ACCESS_FINE_LOCATION
-
Allows the application to access GPS data through the Geolocation
class.
-
ACCESS_NETWORK_STATE and ACCESS_WIFI_STATE
-
Allows the application to access network information through
the NetworkInfo class.
-
CAMERA
-
Allows the application to access the camera.
-
INTERNET
-
Allows the application to make network requests. Also allows
remote debugging.
-
READ_PHONE_STATE
-
Allows the AIR runtime to mute audio when an incoming call
occurs.
-
RECORD_AUDIO
-
Allows the application to access the microphone.
-
WAKE_LOCK and DISABLE_KEYGUARD
-
Allows the application to prevent the device from going to
sleep using the SystemIdleMode class settings.
-
WRITE_EXTERNAL_STORAGE
-
Allows the application to write to the external memory card
on the device.
Application signatures
All application
packages created for the Android platform must be signed. Since AIR
applications on Android are packaged in the native Android APK format,
they are signed in accordance to Android conventions rather than
AIR conventions. While Android and AIR use code signing in a similar
fashion, there are significant differences:
-
On Android,
the signature verifies that the private key is in possession of
the developer, but is not used to verify the identity of the developer.
-
For apps submitted to the Android market, the certificate
must be valid for at least 25 years.
-
Android does not support migrating the package signature
to another certificate. If an update is signed by a different certificate,
then users must uninstall the original app before they can install
the updated app.
-
Two apps signed with the same certificate can specify a shared
ID that permits them to access each others cache and data files.
(Such sharing is not facilitated by AIR.)
Application user IDs
Android uses a Linux
kernel. Every installed app is assigned a Linux-type user ID that
determines its permissions for such operations as file access. Files
in the application, application storage, and temporary directories
are protected from access by file system permissions. Files written
to external storage (in other words, the SD card) can be read, modified,
and deleted by other applications, or by the user, when the SD card
is mounted as a mass storage device on a computer.
Cookies
received with Internet requests are not shared between AIR applications.
Application installation
By default, AIR applications on Android use a shared runtime
library that is maintained and updated by Adobe. Starting in AIR
3, you can bundle your application with a “captive” runtime. An
application installed with a captive runtime uses that version of
the runtime — not the shared AIR runtime, which might also exist
on the device. A captive runtime is not automatically updated when
a new version of the AIR runtime is published.
Important:
When you use a captive runtime, you assume
the responsibility for updating that runtime when relevant security
updates are published by Adobe.
Encrypted data on Android
AIR applications on Android can use the encryption options
available in the built-in SQL database to save encrypted data.
The EncryptedLocalStore class can be used to save data, but that
data is not encrypted. Instead, the Android security model relies
on the application user ID to protect the data from other applications.
Applications that use a shared user ID and which are signed with
the same code signing certificate use the same encrypted local store.
Important:
On a rooted phone, any application running
with root privileges can access the files of any other application.
Thus, data stored using the encrypted local store is not secure
on a rooted device.
|
|
|