Xamarin.Android
Publikowanie swojego Xamarin.Android APK
Szukaj…
Wprowadzenie
W tym temacie przedstawiono informacje o tym, jak przygotować aplikację Xamarin.Android do trybu wydania i jak ją zoptymalizować.
Przygotowywanie pakietu APK w programie Visual Studio
Skończyłeś aplikację, przetestowałeś ją w trybie debugowania i działa idealnie. Teraz chcesz go przygotować do opublikowania w sklepie Google Play.
Dokumentacja Xamarin zapewnia dobre informacje tutaj:
Manifest na Androida
Najpierw w Visual Studio kliknij prawym przyciskiem myszy projekt Xamarin.Android w Eksploratorze rozwiązań i wybierz Właściwości. Następnie przejdź do karty Manifest Androida, aby zobaczyć ten ekran:
W przeciwieństwie do Android Studio lub Eclipse, nie potrzebujesz zestawu pliku AndroidManifest.xml, pisząc; Xamarin i Visual Studio robią to za Ciebie. Aktywności, odbiorcy i usługi są wstawiane do manifestu Androida poprzez zadeklarowanie określonych atrybutów w ich klasach .
Na tym ekranie dostępne są następujące opcje:
- Nazwa aplikacji : jest to nazwa aplikacji, która będzie widoczna dla użytkownika.
- Nazwa paczki : To jest nazwa paczki. Musi być unikalny, co oznacza, że nie może używać tej samej nazwy pakietu innych aplikacji w sklepie Google Play.
- Ikona aplikacji : jest to ikona, która będzie widoczna dla użytkownika, co odpowiada @ drawable / ic_launcher używanemu w projektach Android Studio lub Eclipse.
- Numer wersji : numer wersji jest używany przez Google Play do kontroli wersji. Jeśli chcesz opublikować pakiet APK dla zaktualizowanej wersji aplikacji, musisz dodać 1 do tego numeru dla każdego nowego uaktualnienia.
- Nazwa wersji : jest to nazwa wersji, która będzie wyświetlana użytkownikowi.
- Lokalizacja instalacji : określa, gdzie zostanie zainstalowany pakiet APK, w pamięci urządzenia lub na karcie SD.
- Wymagane uprawnienia : Tutaj określasz, które uprawnienia są niezbędne dla Twojej aplikacji.
Opcje Androida
Na poniższym ekranie możesz skonfigurować opcje kompilatora. Użycie tutaj odpowiednich opcji może znacznie zmniejszyć rozmiar pliku APK, a także zapobiec błędom.
- Konfiguracja : Aktywna (wydanie) .
- Platforma : Aktywna (dowolny procesor) . Są one niezbędne do zbudowania pakietu APK dla sklepu Google Play. Jeśli Konfiguracja jest ustawiona na Debugowanie, nie będzie akceptowana przez Google Play.
- Użyj współdzielonego środowiska wykonawczego : false . Jeśli ustawisz wartość true, APK użyje Mono Runtime do wykonania. Mono Runtime jest instalowany automatycznie podczas debugowania przez USB, ale nie w APK wydania. Jeśli Mono Runtime nie jest zainstalowane w urządzeniu, a opcja ta ma wartość true w APK wydania, aplikacja ulegnie awarii.
- Wygeneruj jeden pakiet (.apk) dla wybranego ABI : false . Utwórz pakiet APK dla jak największej liczby platform, ze względu na kompatybilność.
- Włącz Multi-Dex : prawda , ale możesz ustawić wartość false, jeśli Twoja aplikacja nie jest bardzo złożona (to znaczy ma mniej niż 65536 metod, zobacz tutaj ).
- Włącz Proguard : prawda . Włącza to narzędzie Proguard, które zaciemnia kod Java w Twojej aplikacji. Pamiętaj, że nie dotyczy to kodu .NET; jeśli chcesz zaciemnić kod .NET, musisz użyć Dotfuscator . Więcej informacji na temat Proguard dla Xamarin.Android można znaleźć tutaj .
- Włącz instrumentację dla programistów (debugowanie i profilowanie) : false dla wydania APK.
- Łączenie : SDK i zestawy użytkowników . Spowoduje to, że Xamarin Linker usunie wszystkie nieużywane klasy z SDK i twojego kodu, zmniejszając rozmiar APK.
Ważny
Xamarin.Linker może czasami usuwać klasy, które wydają się nie być używane przez Twój kod, szczególnie jeśli znajdują się w Core projektu (biblioteka PCL). Aby tego uniknąć, możesz ustawić Łączenie na „Tylko zestawy Sdk” lub użyć atrybutu Zachowaj w swoich klasach, na przykład:
PreserveAttribute.cs
namespace My_App_Core.Models
{
public sealed class PreserveAttribute : System.Attribute
{
public bool AllMembers;
public bool Conditional;
}
}
W klasie:
using System;
namespace My_App_Core.Models
{
[Preserve(AllMembers = true)]
public class ServiceException : Exception
{
public int errorCode;
[Preserve(AllMembers = true)]
public ServiceException() { }
[Preserve(AllMembers = true)]
public ServiceException(int errorCode)
{
this.errorCode = errorCode;
}
}
}
- Obsługiwane architektury : Wybierz wszystkie ze względu na kompatybilność.
Po skonfigurowaniu wszystkiego przebuduj projekt, aby upewnić się, że buduje się pomyślnie.
Tworzenie pakietu APK dla trybu Release
Skończyłeś konfigurować swój projekt Androida do wydania. Poniższy samouczek pokazuje, jak wygenerować pakiet APK w programie Visual Studio. Pełny samouczek z dokumentacji Xamarin można znaleźć tutaj:
Aby utworzyć plik APK, kliknij prawym przyciskiem myszy projekt Xamarin.Android w Eksploratorze rozwiązań i wybierz Archiwum ...
Otworzy się menedżer archiwum i rozpocznie archiwizację projektu, przygotowując się do utworzenia pliku APK.
Po zakończeniu archiwizacji projektu kliknij Dystrybucja ..., aby kontynuować.
Na ekranie dystrybucji pojawią się dwie opcje: Ad-hoc i Google Play. Pierwszy utworzy plik APK i zapisze go na komputerze. Drugi opublikuje aplikację bezpośrednio w Google Play.
Zaleca się wybranie pierwszego, aby w razie potrzeby przetestować pakiet APK na innych urządzeniach.
Na poniższym ekranie do podpisania pliku APK potrzebny jest magazyn kluczy Android. Jeśli już go masz, możesz go użyć, klikając opcję Importuj ...; jeśli nie, możesz utworzyć nowy Android Key Store, klikając +.
Tworzenie nowego ekranu Android Key Store:
Aby utworzyć pakiet APK, kliknij Zapisz jako. Może zostać wyświetlony monit o wpisanie hasła magazynu kluczy.
Po zakończeniu możesz kliknąć Otwórz folder na ekranie Archiwum, aby zobaczyć wygenerowany plik APK.
Włączanie MultiDex w twoim Xamarin.Android APK
MultiDex to biblioteka w Android APK, która pozwala aplikacji na ponad 65 536 metod.
Pliki APK dla systemu Android zawierają pliki wykonywalne Dalvik (.dex), które zawierają wygenerowane kody bajtowe skompilowane z kodu Java. Każdy plik .dex może zawierać do 65 536 metod (2 ^ 16).
Wersje systemu operacyjnego Android wcześniejsze niż Android 5.0 Lollipop (API 21) używają środowiska wykonawczego Dalvik, które obsługuje tylko jeden plik .dex na plik APK, ograniczając się do 65 536 metod na plik APK. Począwszy od Androida 5.0, system operacyjny Android wykorzystuje środowisko uruchomieniowe ART, które może obsługiwać więcej niż jeden plik .dex na plik APK, unikając limitu.
Aby przekroczyć limit 65 000 metod w wersjach Androida poniżej API 21, programiści muszą korzystać z biblioteki obsługi MultiDex. MultiDex tworzy dodatkowe pliki klas.dex (klas2.dex, klas3.dex, ...), odwołując się do nich w pliku klas.dex. Gdy aplikacja zaczyna się ładować, używa klasy MultiDexApplication, aby załadować dodatkowe pliki .dex.
Jeśli twoja aplikacja na Androida dąży do uzyskania minimalnej wersji SDK wyższej lub równej API 21 (Android 5.0 Lollipop), nie jest konieczne użycie biblioteki MultiDex, ponieważ system operacyjny natywnie obsługuje dodatkowe pliki .dex. Jeśli jednak ze względów kompatybilności programista chce obsługiwać starszy system operacyjny Android, powinien skorzystać z biblioteki MultiDex.
Jak korzystać z MultiDex w aplikacji Xamarin.Android
Po pierwsze, aby włączyć MultiDex w aplikacji Xamarin.Android, przejdź do projektu Właściwości -> Opcje Androida -> Opakowanie -> Włącz Multi-Dex, jak na poniższym ekranie drukowania:
Następnie musisz utworzyć klasę MultiDexApplication w swojej aplikacji. W katalogu głównym projektu utwórz nową klasę (w Eksploratorze rozwiązań kliknij prawym przyciskiem myszy projekt, Dodaj .. -> Klasa lub Shift + Alt + C). W nowym pliku klasy skopiuj następujący kod, zastępując przestrzeń nazw Sample nazwą nazwą projektu Xamarin.Android.
using System;
using Android.App;
using Android.Runtime;
using Java.Interop;
namespace Sample
{
[Register("android/support/multidex/MultiDexApplication", DoNotGenerateAcw = true)]
public class MultiDexApplication : Application
{
internal static readonly JniPeerMembers _members =
new XAPeerMembers("android/support/multidex/MultiDexApplication", typeof (MultiDexApplication));
internal static IntPtr java_class_handle;
private static IntPtr id_ctor;
[Register(".ctor", "()V", "", DoNotGenerateAcw = true)]
public MultiDexApplication()
: base(IntPtr.Zero, JniHandleOwnership.DoNotTransfer)
{
if (Handle != IntPtr.Zero)
return;
try
{
if (GetType() != typeof (MultiDexApplication))
{
SetHandle(
JNIEnv.StartCreateInstance(GetType(), "()V"),
JniHandleOwnership.TransferLocalRef);
JNIEnv.FinishCreateInstance(Handle, "()V");
return;
}
if (id_ctor == IntPtr.Zero)
id_ctor = JNIEnv.GetMethodID(class_ref, "<init>", "()V");
SetHandle(
JNIEnv.StartCreateInstance(class_ref, id_ctor),
JniHandleOwnership.TransferLocalRef);
JNIEnv.FinishCreateInstance(Handle, class_ref, id_ctor);
}
finally
{
}
}
protected MultiDexApplication(IntPtr javaReference, JniHandleOwnership transfer)
: base(javaReference, transfer)
{
}
internal static IntPtr class_ref
{
get { return JNIEnv.FindClass("android/support/multidex/MultiDexApplication", ref java_class_handle); }
}
protected override IntPtr ThresholdClass
{
get { return class_ref; }
}
protected override Type ThresholdType
{
get { return typeof (MultiDexApplication); }
}
}
}
Jeśli programujesz w programie Visual Studio dla systemu Windows, w narzędziach do budowania zestawu SDK systemu Android występuje błąd, który musisz naprawić, aby poprawnie utworzyć pliki klas.dex podczas budowania projektu.
Przejdź do folderu Android SDK, otwórz folder narzędzi do kompilacji, a pojawią się foldery z numerami kompilatorów Android SDK, takie jak:
C: \ android-sdk \ build-tools \ 23.0.3 \
C: \ android-sdk \ build-tools \ 24.0.1 \
C: \ android-sdk \ build-tools \ 25.0.2 \
W każdym z tych folderów znajduje się plik o nazwie mainClassesDex.bat , skrypt wsadowy używany do tworzenia plików klas.dex. Otwórz każdy plik mainClassesDex.bat za pomocą edytora tekstu (Notepad lub Notepad ++), aw jego skrypcie znajdź i zamień blok:
if DEFINED output goto redirect
call "%java_exe%" -Djava.ext.dirs="%frameworkdir%" com.android.multidex.MainDexListBuilder "%disableKeepAnnotated%" "%tmpJar%" "%params%"
goto afterClassReferenceListBuilder
:redirect
call "%java_exe%" -Djava.ext.dirs="%frameworkdir%" com.android.multidex.MainDexListBuilder "%disableKeepAnnotated%" "%tmpJar%" "%params%" 1>"%output%"
:afterClassReferenceListBuilder
Z blokiem:
SET params=%params:'=%
if DEFINED output goto redirect
call "%java_exe%" -Djava.ext.dirs="%frameworkdir%" com.android.multidex.MainDexListBuilder %disableKeepAnnotated% "%tmpJar%" %params%
goto afterClassReferenceListBuilder
:redirect
call "%java_exe%" -Djava.ext.dirs="%frameworkdir%" com.android.multidex.MainDexListBuilder %disableKeepAnnotated% "%tmpJar%" %params% 1>"%output%"
:afterClassReferenceListBuilder
Zapisz każdy mainClassesDex.bat w edytorze tekstu po zmianach.
Po wykonaniu powyższych kroków powinieneś być w stanie pomyślnie zbudować swoją aplikację Xamarin.Android za pomocą MultiDex.
Włączanie ProGuard w twoim Xamarin.Android APK
ProGuard to narzędzie używane w procesie budowania do optymalizacji i zaciemniania kodu Java twojego APK, a także do usuwania nieużywanych klas. Wynikowy pakiet APK podczas korzystania z ProGuard będzie miał mniejszy rozmiar i trudniej będzie go poddać inżynierii wstecznej (dekompilacji).
ProGuard może być również używany w aplikacjach Xamarin.Android, a także zmniejszy rozmiar pliku APK i zaciemni kod Java. Pamiętaj jednak, że zaciemnianie ProGuard dotyczy tylko kodu Java. Aby zaciemnić kod .NET, programista powinien użyć Dotfuscator lub podobnych narzędzi.
Jak korzystać z ProGuard w aplikacji Xamarin.Android
Po pierwsze, aby włączyć ProGuard w aplikacji Xamarin.Android, przejdź do projektu Właściwości -> Opcje Androida -> Opakowanie -> Włącz ProGuard, jak na poniższym ekranie drukowania:
Umożliwia to ProGuard podczas tworzenia aplikacji.
Xamarin.Android domyślnie ustawia własne konfiguracje ProGuard, które można znaleźć w folderach obj/Debug/proguard lub obj/Release/proguard , w plikach proguard_project_primary.cfg , proguard_project_references.cfg i proguard_xamarin.cfg . Te trzy pliki są łączone jako konfiguracje ProGuard i są automatycznie tworzone przez Xamarin podczas budowania.
Jeśli deweloper chce dalej dostosowywać opcje ProGuard, może utworzyć plik w katalogu głównym projektu o nazwie proguard.cfg (inne nazwy też są ważne, o ile rozszerzenie to .cfg) i ustawić akcję budowania na ProguardConfiguration, jak na zdjęciu poniżej:
W pliku można wstawić niestandardowe opcje ProGuard, takie jak -dontwarn , -keep class i inne .
Ważny
Jak na razie (kwiecień / 2017 r.), Zwykle pobierany zestaw SDK systemu Android ma starą wersję ProGuard, która może powodować błędy podczas budowania aplikacji przy użyciu Java 1.8. Podczas budowania lista błędów wyświetla następujący komunikat:
Error
Can't read [C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\MonoAndroid\v7.0\mono.android.jar]
(Can't process class [android/app/ActivityTracker.class] (Unsupported class version number [52.0] (maximum 51.0, Java 1.7))) [CREATEMULTIDEXMAINDEXCLASSLIST]
Aby rozwiązać ten problem, musisz pobrać najnowszą wersję ProGuard ( tutaj ) i skopiować zawartość pliku .zip na android-sdk\tools\proguard\ . To zaktualizuje ProGuard i proces budowania powinien przebiegać bez problemów.
Następnie powinieneś być w stanie pomyślnie zbudować swoją aplikację Xamarin.Android za pomocą ProGuard.
„Tajemnicze” błędy związane z ProGuard i Linkerem
Zrobiłeś świetną aplikację i przetestowałeś ją w Debugowaniu, z dobrymi wynikami. Wszystko działało dobrze!
Ale potem zdecydowałeś się przygotować swoją aplikację do wydania. Skonfigurowałeś MultiDex, ProGuard i Linker, a potem przestał działać.
Ten samouczek ma na celu pomóc Ci znaleźć typowe problemy związane z ProGuard i Linkerem, które mogą powodować tajemnicze błędy.
Zrozumienie Xamarin.Linker
Xamarin.Linker to narzędzie w procesie budowania, które usuwa nieużywany kod i klasy z kodu .NET (nie kodu Java) . We właściwościach projektu -> Opcje Androida -> Linker, pojawi się pole wyboru Łączenie z opcjami:
Brak : żaden kod nie został usunięty.
Tylko zestawy Sdk : Ta opcja powoduje, że Xamarin.Linker sprawdza, czy nie jest używany kod tylko w bibliotekach Xamarin. Ta opcja jest bezpieczna.
Sdk i zespoły użytkowników : Ta opcja powoduje, że Xamarin.Linker sprawdza, czy nie jest używany kod w bibliotekach Xamarin i w kodzie projektu (w tym PCL, komponenty Xamarin i pakiety NuGet). Ta opcja nie zawsze jest bezpieczna!
Korzystając z opcji Sdk i zestawów użytkowników, Xamarin.Linker może myśleć, że części kodu są nieużywane, podczas gdy w rzeczywistości są bardzo używane! Może to spowodować, że niektóre biblioteki przestaną działać poprawnie i będą powodować błędy w aplikacji.
Aby Xamarin.Linker nie usuwał kodu, istnieją 3 opcje:
- Ustawienie opcji Łączenie na Brak lub Tylko zespoły Sdk;
- Pomiń łączenie zestawów;
- Korzystanie z atrybutu Zachowaj.
Przykład 2. Pomiń łączenie zestawów:
W poniższym przykładzie użycie Xamarin.Linker spowodowało, że pakiet NuGet ( Octokit ) działa dobrze, aby przestać działać, ponieważ nie mógł się już połączyć z Internetem:
[0:] ERROR
[0:] SOURCE: mscorlib
[0:] MESSAGE: Object reference not set to an instance of an object.
[0:] STACK TRACE: at Octokit.PocoJsonSerializerStrategy.DeserializeObject (System.Object value, System.Type type) [0x003d8] in D:\repos\octokit.net\Octokit\SimpleJson.cs:1472
at Octokit.Internal.SimpleJsonSerializer+GitHubSerializerStrategy.DeserializeObject (System.Object value, System.Type type) [0x001c3] in D:\repos\octokit.net\Octokit\Http\SimpleJsonSerializer.cs:165
at Octokit.SimpleJson.DeserializeObject (System.String json, System.Type type, Octokit.IJsonSerializerStrategy jsonSerializerStrategy) [0x00007] in D:\repos\octokit.net\Octokit\SimpleJson.cs:583
at Octokit.SimpleJson.DeserializeObject[T] (System.String json, Octokit.IJsonSerializerStrategy jsonSerializerStrategy) [0x00000] in D:\repos\octokit.net\Octokit\SimpleJson.cs:595
at Octokit.Internal.SimpleJsonSerializer.Deserialize[T] (System.String json) [0x00000] in D:\repos\octokit.net\Octokit\Http\SimpleJsonSerializer.cs:21
at Octokit.Internal.JsonHttpPipeline.DeserializeResponse[T] (Octokit.IResponse response) [0x000a7] in D:\repos\octokit.net\Octokit\Http\JsonHttpPipeline.cs:62
at Octokit.Connection+<Run>d__54`1[T].MoveNext () [0x0009c] in D:\repos\octokit.net\Octokit\Http\Connection.cs:574
--- End of stack trace from previous location where exception was thrown ---
Aby biblioteka znów zaczęła działać, konieczne było dodanie nazwy odwołania do pakietu w polu Pomiń zespoły łączące, znajdujące się w projekcie -> Właściwości -> Opcje Androida -> Linker, jak na poniższym obrazku:
Następnie biblioteka zaczęła działać bez żadnych problemów.
Przykład dla 3. Użycie atrybutu Zachowaj:
Xamarin.Linker postrzega jako nieużywany kod głównie kod z klas modeli w rdzeniu twojego projektu.
Aby zachować klasę podczas procesu łączenia, możesz użyć atrybutu Zachowaj.
Najpierw utwórz w rdzeniu projektu klasę o nazwie PreserveAttribute.cs , wstaw następujący kod i zastąp przestrzeń nazw przestrzenią nazw projektu:
PreserveAttribute.cs:
namespace My_App_Core.Models
{
public sealed class PreserveAttribute : System.Attribute
{
public bool AllMembers;
public bool Conditional;
}
}
W każdej klasie modeli rdzenia projektu wstaw atrybut Zachowaj, jak w poniższym przykładzie:
Country.cs:
using System;
using System.Collections.Generic;
namespace My_App_Core.Models
{
[Preserve(AllMembers = true)]
public class Country
{
public String name { get; set; }
public String ISOcode { get; set; }
[Preserve(AllMembers = true)]
public Country(String name, String ISOCode)
{
this.name = name;
this.ISOCode = ISOCode;
}
}
}
Następnie proces łączenia nie usunie już zachowanego kodu.
Zrozumienie ProGuard
ProGuard to narzędzie w procesie budowania, które usuwa nieużywany kod i klasy z kodu Java . To również zaciemnia i optymalizuje kod.
Jednak ProGuard może czasami usunąć kod, który uważa za nieużywany, gdy nie jest. Aby tego uniknąć, programista musi debugować aplikację (w Android Device Monitor i Visual Studio Debug) i wykryć, która klasa została usunięta, aby następnie skonfigurować plik konfiguracyjny ProGuard, aby zachować klasę.
Przykład
W poniższym przykładzie ProGuard usunął dwie klasy (Android.Support.V7.Widget.FitWindowsLinearLayout i Android.Support.Design.Widget.AppBarLayout) używane w plikach układu AXML, które były postrzegane jako nieużywane w kodzie. Usunięcie spowodowało wyjątek ClassNotFoundException w kodzie Java podczas renderowania układu działania:
layout_activitymain.axml:
<?xml version="1.0" encoding="utf-8"?>
<android.support.v4.widget.DrawerLayout
xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:app="http://schemas.android.com/apk/res-auto"
xmlns:tools="http://schemas.android.com/tools"
android:id="@+id/activitymain_drawerlayout"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:fitsSystemWindows="true" <!-- ### HERE ### -->
tools:openDrawer="start">
<RelativeLayout
android:layout_width="match_parent"
android:layout_height="match_parent"
android:fitsSystemWindows="true">
<!-- ### HERE ## -->
<android.support.design.widget.AppBarLayout
android:id="@+id/activitymain_appbarlayout"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:theme="@style/AppTheme.AppBarOverlay">
...
LogCat pokazuje błąd podczas tworzenia układu w SetContentView:
Aby naprawić ten błąd, konieczne było dodanie następujących wierszy do pliku konfiguracyjnego ProGuard projektu:
-keep public class android.support.v7.widget.FitWindowsLinearLayout
-keep public class android.support.design.widget.AppBarLayout
Po tym nie było więcej błędów podczas tworzenia układu.
Ostrzeżenia ProGuard
ProGuard czasami wyświetla ostrzeżenia na liście błędów po zbudowaniu projektu. Chociaż pojawiają się pytania, czy aplikacja działa poprawnie, czy nie, nie wszystkie ostrzeżenia wskazują na problemy, zwłaszcza jeśli aplikacja zostanie pomyślnie zbudowana.
Jednym z przykładów jest użycie biblioteki Picasso : podczas korzystania z ProGuard może to pokazywać ostrzeżenia, takie jak okio.Okio: can't find referenced class (...) lub can't write resource [META-INF/MANIFEST.MF] (Duplicate zip entry [okhttp.jar:META-INF/MANIFEST.MF]) (...) , ale aplikacja się kompiluje, a biblioteka działa bez problemów.