Na platformie Android w celu dodawania informacji do manifestu aplikacji systemu Android, czyli pliku właściwości aplikacji używanego przez system operacyjny Android, można używać elementu
android
deskryptora aplikacji. Podczas tworzenia pakietu APK narzędzie ADT automatycznie tworzy plik Manifest.xml systemu Android. Środowisko AIR ustawia kilka właściwości wartości wymaganych do działania pewnych funkcji. Wszelkie inne właściwości ustawione w sekcji systemu Android deskryptora aplikacji AIR są dodawane do odpowiedniej sekcji pliku Manifest.xml.
Uwaga:
W przypadku większości aplikacji AIR uprawnienia systemu Android wymagane przez aplikację należy ustawiać w elemencie
android
. Zwykle nie trzeba ustawiać żadnych innych właściwości.
Można ustawiać wyłącznie atrybuty przyjmujące wartości ciągów, liczb całkowitych lub wartości logicznych. Nie jest obsługiwane ustawianie odniesień do zasobów w pakiecie aplikacji.
Uwaga:
Środowisko wykonawcze wymaga zestawu SDK nie starszej niż 14. Aby utworzyć aplikację wyłącznie dla nowszych wersji, należy zawrzeć w manifeście wyrażenie
<uses-sdk android:minSdkVersion=""></uses-sdk>
z uwzględnieniem właściwej wersji.
Zarezerwowane ustawienia manifestu systemu Android
W celu zapewnienia prawidłowego działania aplikacji i środowiska wykonawczego kilka wpisów manifestu w tworzonym dokumencie manifestu systemu Android jest ustawianych przez środowisko AIR. Nie można definiować następujących ustawień:
Element manifest
Nie można ustawiać następujących atrybutów elementu manifest:
-
package
-
android:versionCode
-
android:versionName
-
xmlns:android
Element activity
Nie można ustawiać następujących atrybutów dla głównego elementu activity:
-
android:label
-
android:icon
Element application
Nie można ustawiać następujących atrybutów elementu application:
Uprawnienia w systemie Android
Model bezpieczeństwa w systemie Android wymaga, aby każda aplikacja żądała uprawnień w celu korzystania z funkcji mających następstwa w zakresie bezpieczeństwa lub prywatności. Te uprawnienia muszą zostać określone w momencie pakowania aplikacji i nie można ich zmieniać podczas jej działania. Gdy użytkownik instaluje aplikację, system operacyjny Android informuje, jakich uprawnień żąda ta aplikacja. Jeśli nie nastąpi żądanie uprawnienia wymaganego dla funkcji, system operacyjny Android może zgłosić wyjątek, gdy aplikacja uzyska dostęp do funkcji, ale nie musi to nastąpić. Wyjątki są przekazywane do aplikacji przez środowisko wykonawcze. W przypadku niezgłoszonego niepowodzenia do dziennika systemu Android jest dodawany komunikat o niepowodzeniu dotyczącym uprawnienia.
W środowisku AIR uprawnienia systemu Android są określane w elemencie
android
deskryptora aplikacji. Do dodawania uprawnień służy następujący format (gdzie fragment PERMISSION_NAME jest nazwą uprawnienia w systemie Android):
<android>
<manifestAdditions>
<![CDATA[
<manifest>
<uses-permission android:name="android.permission.PERMISSION_NAME" />
</manifest>
]]>
</manifestAdditions>
</android>
Instrukcje uses-permissions w elemencie
manifest
są dodawane bezpośrednio do dokumentu manifestu systemu Android.
Do korzystania z różnych funkcji środowiska AIR są wymagane następujące uprawnienia:
-
ACCESS_COARSE_LOCATION
-
Umożliwia aplikacji uzyskiwanie za pośrednictwem klasy Geolocation dostępu do danych o lokalizacji określanych przy użyciu sieci Wi-Fi oraz sieci komórkowych.
-
ACCESS_FINE_LOCATION
-
Umożliwia aplikacji uzyskiwanie dostępu do danych systemu GPS za pośrednictwem klasy Geolocation.
-
ACCESS_NETWORK_STATE i ACCESS_WIFI_STATE
-
Umożliwiają aplikacji uzyskiwanie dostępu do informacji o sieci za pośrednictwem klasy NetworkInfo.
-
CAMERA
-
Umożliwia aplikacji uzyskiwanie dostępu do kamery.
Uwaga:
W przypadku żądania uprawnienia do korzystania z funkcji kamery system Android zakłada, że aplikacja również wymaga kamery. Jeśli kamera jest opcjonalną funkcją aplikacji, wówczas należy dodać do manifestu element
uses-feature
dotyczący kamery, ustawiając wartość
false
dla atrybutu required. Zobacz
Filtrowanie zgodności w systemie Android
.
-
INTERNET
-
Umożliwia aplikacji realizowania żądań dotyczących sieci. Pozwala także na zdalne debugowanie.
-
READ_PHONE_STATE
-
Umożliwia środowisku AIR wyciszanie dźwięków podczas połączeń telefonicznych. To uprawnienie należy ustawić, jeśli podczas działania w tle aplikacja odtwarza dźwięk.
-
RECORD_AUDIO
-
Umożliwia aplikacji uzyskiwanie dostępu do mikrofonu.
-
WAKE_LOCK i DISABLE_KEYGUARD
-
Umożliwiają aplikacji blokowanie przejścia urządzenia w tryb uśpienia przy użyciu ustawień klasy SystemIdleMode.
-
WRITE_EXTERNAL_STORAGE
-
Umożliwia aplikacji zapisywanie danych na zewnętrznej karcie pamięci podłączonej do urządzenia.
Na przykład w celu ustawienia uprawnień dla aplikacji wymagającej wszystkich uprawnień można dodać następujący deskryptor aplikacji:
<android>
<manifestAdditions>
<![CDATA[
<manifest>
<uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
<uses-permission android:name="android.permission.ACCESS_WIFI_STATE" />
<uses-permission android:name="android.permission.CAMERA" />
<uses-permission android:name="android.permission.DISABLE_KEYGUARD" />
<uses-permission android:name="android.permission.INTERNET" />
<uses-permission android:name="android.permission.READ_PHONE_STATE" />
<uses-permission android:name="android.permission.RECORD_AUDIO" />
<uses-permission android:name="android.permission.WAKE_LOCK" />
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />
</manifest>
]]>
</manifestAdditions>
</android>
Własne schematy identyfikatorów URI w systemie Android
Do uruchamiania aplikacji AIR ze strony internetowej lub z natywnej aplikacji systemu Android można używać własnego schematu identyfikatora URI. Obsługa własnych identyfikatorów URI jest oparta na filtrach metody konwersji określonych w manifeście systemu Android, dlatego tej techniki nie można używać na innych platformach.
Aby użyć własnego identyfikatora URI, do deskryptora aplikacji należy dodać w bloku
<android>
filtr metody konwersji. W poniższym przykładzie należy określić oba elementy
intent-filter
. Wyrażenie
<data android:scheme="
my-customuri
"/>
należy edytować w taki sposób, aby odzwierciedlało ono ciąg URI dla danego własnego schematu.
<android>
<manifestAdditions>
<![CDATA[
<manifest>
<application>
<activity>
<intent-filter>
<action android:name="android.intent.action.MAIN"/>
<category android:name="android.intent.category.LAUNCHER"/>
</intent-filter>
<intent-filter>
<action android:name="android.intent.action.VIEW"/>
<category android:name="android.intent.category.BROWSABLE"/>
<category android:name="android.intent.category.DEFAULT"/>
<data android:scheme="my-customuri"/>
</intent-filter>
</activity>
</application>
</manifest>
]]>
</manifestAdditions>
</android>
Filtr metody konwersji informuje system operacyjny Android, że aplikacja jest dostępna do wykonania danej operacji. W przypadku własnego schematu URI oznacza to, że użytkownik kliknął łącze korzystające z tego schematu URI (a przeglądarka nie wie, jak obsłużyć schemat).
W przypadku wywołania aplikacji przez własny schemat URI obiekt NativeApplication wywołuje zdarzenie
invoke
. Adres URL łącza, łącznie z parametrami zapytania, jest umieszczany w tablicy
arguments
obiektu InvokeEvent. Można używać dowolnej liczby filtrów metod konwersji.
Uwaga:
Łącza w wystąpieniu klasy StageWebView nie umożliwiają otwierania adresów URL korzystających z własnego schematu URI.
Filtrowanie zgodności w systemie Android
Aby określić, czy dana aplikacja jest zgodna z danym urządzeniem, system operacyjny Android korzysta z szeregu elementów w pliku manifestu tej aplikacji. Dodawanie tych informacji do manifestu jest opcjonalne. Jeśli te elementy nie zostaną dodane, aplikację będzie można instalować na dowolnym urządzeniu z systemem Android. Jednak może ona nie działać prawidłowo na pewnych urządzeniach z systemem Android. Na przykład aplikacja do obsługi kamery nie będzie pomocna na telefonie, który nie jest wyposażony w kamerę.
Niektóre znaczniki manifestu systemu Android, których można używać do filtrowania:
Aplikacje korzystające z kamery
W przypadku żądania dla aplikacji uprawnień dotyczących kamery system Android zakłada, że aplikacja wymaga wszystkich dostępnych funkcji kamery, łącznie z automatycznym ustawianiem ostrości i lampą błyskową. Jeśli aplikacja nie wymaga wszystkich funkcji kamery lub jeśli kamera jest funkcją opcjonalną, należy ustawić dla kamery poszczególne elementy
uses-feature
w celu określenia, że są one opcjonalne. W przeciwnym razie użytkownicy urządzeń, które nie mają jednej funkcji lub które w ogóle nie mają kamery, nie będą mogli znaleźć danej aplikacji w sklepie Android Market.
Poniższy przykład ilustruje, w jaki sposób zażądać uprawnienia dotyczącego kamery i uczynić wszystkie funkcje aparatu opcjonalnymi.
<android>
<manifestAdditions>
<![CDATA[
<manifest>
<uses-permission android:name="android.permission.CAMERA" />
<uses-feature android:name="android.hardware.camera" android:required="false"/>
<uses-feature android:name="android.hardware.camera.autofocus" android:required="false"/>
<uses-feature android:name="android.hardware.camera.flash" android:required="false"/>
</manifest>
]]>
</manifestAdditions>
</android>
Aplikacje do nagrywania dźwięku
W przypadku żądania uprawnień do nagrywania dźwięku system Android zakłada również, że aplikacja wymaga mikrofonu. Jeśli nagrywanie dźwięku jest opcjonalną funkcją aplikacji, można określić, że mikrofon nie jest konieczny, dodając znacznik uses-feature. W przeciwnym razie użytkownicy urządzeń, które nie mają mikrofonu, nie będą mogli znaleźć danej aplikacji w sklepie Android Market.
Poniższy przykład ilustruje sposób żądania uprawnień do używania mikrofonu, a jednocześnie ustawienia obsługi sprzętowej mikrofonu jako opcjonalnej.
<android>
<manifestAdditions>
<![CDATA[
<manifest>
<uses-permission android:name="android.permission.RECORD_AUDIO" />
<uses-feature android:name="android.hardware.microphone" android:required="false"/>
</manifest>
]]>
</manifestAdditions>
</android>
Lokalizacja instalacji
Ustawiając dla atrybutu
installLocation
elementu
manifest
systemu Android wartość
auto
lub
preferExternal
, można zezwolić na instalację lub przeniesienie aplikacji na zewnętrzną kartę pamięci.
<android>
<manifestAdditions>
<![CDATA[
<manifest android:installLocation="preferExternal"/>
]]>
</manifestAdditions>
</android>
System operacyjny Android nie gwarantuje, że aplikacja zostanie zainstalowana w pamięci zewnętrznej. Użytkownik może również przenosić aplikację między pamięcią wewnętrzną i zewnętrzną za pomocą aplikacji ustawień systemowych.
Nawet w przypadku zainstalowania w pamięci zewnętrznej bufor aplikacji oraz dane użytkownika, takie jak zawartość katalogu magazynu aplikacji, obiekty udostępnione i pliki tymczasowe, są nadal przechowywane w pamięci wewnętrznej. W celu uniknięcia zbyt dużego użycia pamięci wewnętrznej należy rozsądnie wybierać dane zapisywane w katalogu magazynu aplikacji. Duże ilości danych należy zapisywać na karcie SD, korzystając z lokalizacji
File.userDirectory
lub
File.documentsDirectory
(które w systemie Android są odwzorowywane na katalog główny karty SD).
Włączanie programu Flash Player i innych dodatków plug-in w obiekcie StageWebView
W systemie Android 3.0+ aplikacja musi włączyć przyspieszanie sprzętowe w elemencie aplikacji Android, aby zawartość dodatku plug-in była wyświetlana w obiekcie StageWebView. Aby włączyć renderowanie dodatków plug-in, należy ustawić dla atrybutu
android:hardwareAccelerated
elementu
application
wartość
true
.
<android>
<manifestAdditions>
<![CDATA[
<manifest>
<application android:hardwareAccelerated="true"/>
</manifest>
]]>
</manifestAdditions>
</android>
Głębia koloru
Środowisko wykonawcze AIR 3 i nowsze wersje ustawiają renderowanie kolorów 32-bitowych. We wcześniejszych wersjach środowiska wykonawczego AIR stosowane są kolory 16-bitowe. Aby określić, że środowisko wykonawcze ma używać kolorów 16-bitowych, można użyć elementu <colorDepth> w deskryptorze aplikacji:
<android>
<colorDepth>16bit</colorDepth>
<manifestAdditions>...</manifestAdditions>
</android>
Stosowanie 16-bitowej głębi koloru może zwiększyć wydajność renderowania, lecz obniża jakość kolorów.
|
|
|