Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
Nadat een toepassing is gecodeerd en getest, is het noodzakelijk om een pakket voor te bereiden op distributie. De eerste taak bij het voorbereiden van dit pakket is het bouwen van de toepassing voor release. Dit omvat voornamelijk het instellen van bepaalde toepassingskenmerken.
Gebruik de volgende stappen om de app te bouwen voor release:
Geef het toepassingspictogram op: elke Xamarin.Android-toepassing moet een toepassingspictogram hebben opgegeven. Hoewel dit technisch niet nodig is, vereisen sommige markten, zoals Google Play, dit.
Versie van de toepassing : deze stap omvat het initialiseren of bijwerken van de versiegegevens. Dit is belangrijk voor toekomstige toepassingsupdates en om ervoor te zorgen dat de gebruikers weten welke versie van de toepassing ze hebben geïnstalleerd.
Verklein de APK – De grootte van de uiteindelijke APK kan aanzienlijk worden verminderd met behulp van de Xamarin.Android-linker op de beheerde code en ProGuard op de Java-bytecode.
Bescherm de toepassing – Voorkom dat gebruikers of aanvallers de toepassing debuggen, ermee knoeien, of er reverse-engineering op uitvoeren door debugging uit te schakelen, beheerde code te obfusceren, anti-debugging en anti-manipulatie toe te voegen en systeemeigen compilatie te gebruiken.
Verpakkingsinstellingen instellen – Verpakkingsinstellingen beheersen de creatie van het Android-application package (APK). Met deze stap optimaliseert u de APK, beveiligt u de assets en modulariseert u de verpakking indien nodig. Daarnaast kunt u uw gebruikers voorzien van een Android-app-bundel die is geoptimaliseerd voor hun apparaten.
Compileren : met deze stap worden de code en assets gecompileerd om te controleren of deze wordt gebouwd in de releasemodus.
Archief voor publiceren : met deze stap wordt de app gebouwd en in een archief opgeslagen voor ondertekening en publicatie.
Elk van deze stappen wordt hieronder uitgebreid beschreven.
Het toepassingspictogram opgeven
Het wordt sterk aanbevolen dat elke Xamarin.Android-toepassing een toepassingspictogram opgeeft. Sommige marketplaces voor toepassingen staan niet toe dat een Android-toepassing zonder één toepassing wordt gepubliceerd. De Icon eigenschap van het Application kenmerk wordt gebruikt om het toepassingspictogram voor een Xamarin.Android-project op te geven.
Geef in Visual Studio 2017 en hoger het toepassingspictogram op via de sectie Android Manifest van projecteigenschappen, zoals wordt weergegeven in de volgende schermopname:
In deze voorbeelden @drawable/icon verwijst u naar een pictogrambestand dat zich in Resources/drawable/icon.png bevindt (houd er rekening mee dat de .png extensie niet is opgenomen in de resourcenaam). Dit kenmerk kan ook worden gedeclareerd in het bestand Properties\AssemblyInfo.cs, zoals wordt weergegeven in dit voorbeeldfragment:
[assembly: Application(Icon = "@drawable/icon")]
Normaal gesproken using Android.App wordt boven aan AssemblyInfo.cs gedeclareerd (de naamruimte van het Application kenmerk is Android.App); mogelijk moet u deze using instructie echter toevoegen als deze nog niet aanwezig is.
Versie van de toepassing
Versiebeheer is belangrijk voor onderhoud en distributie van Android-toepassingen. Zonder enige versiebeheer is het moeilijk om te bepalen of of een toepassing moet worden bijgewerkt. Android herkent twee verschillende soorten informatie om u te helpen bij versiebeheer:
Versienummer : een geheel getal (intern gebruikt door Android en de toepassing) die de versie van de toepassing vertegenwoordigt. De meeste toepassingen beginnen met deze waarde ingesteld op 1 en worden vervolgens verhoogd met elke build. Deze waarde heeft geen relatie of affiniteit met het versienaamkenmerk (zie hieronder). Toepassingen en publicatieservices mogen deze waarde niet weergeven voor gebruikers. Deze waarde wordt opgeslagen in het AndroidManifest.xml-bestand als
android:versionCode.Versienaam : een tekenreeks die alleen wordt gebruikt voor het communiceren van informatie aan de gebruiker over de versie van de toepassing (zoals geïnstalleerd op een specifiek apparaat). De versienaam is bedoeld om te worden weergegeven voor gebruikers of in Google Play. Deze tekenreeks wordt niet intern gebruikt door Android. De versienaam kan elke tekenreekswaarde zijn waarmee een gebruiker de build kan identificeren die op het apparaat is geïnstalleerd. Deze waarde wordt opgeslagen in het AndroidManifest.xml-bestand als
android:versionName.
In Visual Studio kunnen deze waarden worden ingesteld in de sectie Android-manifest van projecteigenschappen, zoals wordt weergegeven in de volgende schermopname:
De APK verkleinen
Xamarin.Android-API's kunnen kleiner worden gemaakt via een combinatie van de Xamarin.Android-linker, waarmee onnodige beheerde code wordt verwijderd en het ProGuard-hulpprogramma uit de Android SDK, waarmee ongebruikte Java-bytecode wordt verwijderd. Het buildproces maakt eerst gebruik van de Xamarin.Android-linker om de app te optimaliseren op het niveau van de beheerde code (C#) en vervolgens gebruikt het later ProGuard (indien ingeschakeld) om de APK te optimaliseren op java-bytecodeniveau.
Linker configureren
De releasemodus schakelt de gedeelde runtime uit en schakelt het koppelen in, zodat de toepassing alleen de onderdelen van Xamarin.Android verzendt die tijdens runtime zijn vereist. De linker in Xamarin.Android maakt gebruik van statische analyse om te bepalen welke assembly's, typen en typeleden worden gebruikt of waarnaar wordt verwezen door een Xamarin.Android-toepassing. De linker verwijdert vervolgens alle ongebruikte assembly's, typen en leden die niet worden gebruikt (of waarnaar wordt verwezen). Dit kan leiden tot een aanzienlijke vermindering van de pakketgrootte. Denk bijvoorbeeld aan het HelloWorld-voorbeeld , dat een vermindering van 83% in de uiteindelijke grootte van de APK ondervindt:
Configuratie: Geen – Xamarin.Android 4.2.5 Size = 17,4 MB.
Configuratie: Alleen SDK-assemblies – Xamarin.Android 4.2.5 Grootte = 3,0 MB.
Stel linkeropties in via de sectie Android-opties van het projecteigenschappen:
Het vervolgkeuzemenu Koppelen biedt de volgende opties voor het beheren van de linker:
Geen – Hiermee wordt de linker uitgeschakeld; er wordt geen koppeling uitgevoerd.
Alleen SDK-assembly's : hiermee worden alleen de assembly's gekoppeld die vereist zijn voor Xamarin.Android. Andere samenstellingen zijn niet gekoppeld.
Sdk en gebruikersassembly's : hiermee worden alle assembly's gekoppeld die vereist zijn voor de toepassing, en niet alleen de assembly's die vereist zijn voor Xamarin.Android.
Koppelen kan onbedoelde bijwerkingen opleveren, dus het is belangrijk dat een toepassing opnieuw wordt getest in de releasemodus op een fysiek apparaat.
ProGuard
ProGuard is een Android SDK-hulpprogramma waarmee Java-code wordt gekoppeld en verborgen. ProGuard wordt normaal gesproken gebruikt om kleinere toepassingen te maken door de footprint van grote opgenomen bibliotheken (zoals Google Play Services) in uw APK te verminderen. ProGuard verwijdert ongebruikte Java-bytecode, waardoor de resulterende app kleiner wordt. Als u bijvoorbeeld ProGuard gebruikt voor kleine Xamarin.Android-apps, bereikt u meestal ongeveer 24% vermindering van de grootte. Als u ProGuard gebruikt voor grotere apps met meerdere bibliotheekafhankelijkheden, bereikt u meestal een nog grotere groottevermindering.
ProGuard is geen alternatief voor de Xamarin.Android-linker. De Xamarin.Android-koppeling koppelt beheerde code, terwijl ProGuard Java-bytecode koppelt. Het buildproces maakt eerst gebruik van de Xamarin.Android-linker om de beheerde (C#)-code in de app te optimaliseren en vervolgens gebruikt het later ProGuard (indien ingeschakeld) om de APK te optimaliseren op java-bytecodeniveau.
Wanneer ProGuard inschakelen is ingeschakeld, voert Xamarin.Android het ProGuard-hulpprogramma uit op de resulterende APK. Er wordt tijdens de build een ProGuard-configuratiebestand gegenereerd en gebruikt door ProGuard. Xamarin.Android ondersteunt ook aangepaste ProguardConfiguration-buildacties . U kunt een aangepast ProGuard-configuratiebestand toevoegen aan uw project, er met de rechtermuisknop op klikken en het selecteren als een build-actie, zoals wordt weergegeven in dit voorbeeld:
ProGuard is standaard uitgeschakeld. De optie ProGuard inschakelen is alleen beschikbaar wanneer het project is ingesteld op de releasemodus . Alle ProGuard-buildacties worden genegeerd, tenzij ProGuard inschakelen is aangevinkt. De Xamarin.Android ProGuard-configuratie verdoezelt de APK niet en het is niet mogelijk om verborgen te maken, zelfs niet met aangepaste configuratiebestanden. Als u obfuscatie wilt gebruiken, zie Application Protection met Dotfuscator.
Zie ProGuard voor meer informatie over het gebruik van het ProGuard-hulpprogramma.
De toepassing beveiligen
Foutopsporing uitschakelen
Tijdens de ontwikkeling van een Android-toepassing wordt foutopsporing uitgevoerd met behulp van het Java Debug Wire Protocol (JDWP). Dit is een technologie waarmee hulpprogramma's zoals adb kunnen communiceren met een JVM voor foutopsporing. JDWP is standaard ingeschakeld voor foutopsporingsversies van een Xamarin.Android-toepassing. Hoewel JDWP belangrijk is tijdens de ontwikkeling, kan dit een beveiligingsprobleem vormen voor uitgebrachte toepassingen.
Belangrijk
Schakel altijd de foutopsporingsstatus in een uitgebrachte toepassing uit, omdat het mogelijk is (via JDWP) om volledige toegang te krijgen tot het Java-proces en willekeurige code uit te voeren in de context van de toepassing als deze foutopsporingsstatus niet is uitgeschakeld.
Het Android-manifest bevat het android:debuggable kenmerk, waarmee wordt bepaald of de toepassing fouten kan opsporen. Het wordt beschouwd als een goede gewoonte om het android:debuggable kenmerk in te stellen op false. De eenvoudigste manier om dit te doen is door een voorwaardelijke compile-instructie toe te voegen in AssemblyInfo.cs:
#if DEBUG
[assembly: Application(Debuggable=true)]
#else
[assembly: Application(Debuggable=false)]
#endif
Houd er rekening mee dat builds voor foutopsporing automatisch bepaalde machtigingen instellen om foutopsporing gemakkelijker te maken (zoals Internet en ReadExternalStorage). Release-builds gebruiken echter alleen de machtigingen die u expliciet configureert. Als u merkt dat u overschakelt naar de release-build waardoor uw app een machtiging verliest die beschikbaar was in de build voor foutopsporing, controleert u of u deze machtiging expliciet hebt ingeschakeld in de lijst Vereiste machtigingen , zoals beschreven in Machtigingen.
Toepassingsbeveiliging met Dotfuscator
Zelfs als foutopsporing is uitgeschakeld, is het nog steeds mogelijk voor aanvallers om een toepassing opnieuw te verpakken, configuratieopties of machtigingen toe te voegen of te verwijderen. Hierdoor kunnen ze reverse-engineeren, fouten opsporen of knoeien met de toepassing. Dotfuscator Community Edition (CE) kan worden gebruikt om beheerde code te verdoezelen en code voor runtimebeveiligingsstatusdetectie in te voeren in een Xamarin.Android-app tijdens de build om te detecteren en te reageren als de app wordt uitgevoerd op een geroot apparaat.
Dotfuscator CE is opgenomen in Visual Studio 2017. Als u Dotfuscator wilt gebruiken, klikt u op Extra > PreEmptive Protection - Dotfuscator.
Als u Dotfuscator CE wilt configureren, raadpleegt u Dotfuscator Community Edition gebruiken met Xamarin. Zodra deze is geconfigureerd, beveiligt Dotfuscator CE automatisch elke build die wordt gemaakt.
Assemblages bundelen in systeemeigen code
Wanneer deze optie is ingeschakeld, worden assembly's gebundeld in een systeemeigen gedeelde bibliotheek. Hierdoor kunnen assembly's worden gecomprimeerd, waardoor kleinere .apk bestanden worden toegestaan. Montagecompressie geeft ook een minimale vorm van verduistering; daar mag niet op worden vertrouwd.
Voor deze optie is een Enterprise-licentie vereist en is alleen beschikbaar wanneer Snelle implementatie gebruiken is uitgeschakeld. Assembly's bundelen tot systeemeigen code is standaard uitgeschakeld.
Houd er rekening mee dat de optie Bundel in systeemeigen codeniet betekent dat de assembly's worden gecompileerd in systeemeigen code. Het is niet mogelijk om AOT-compilatie te gebruiken om assembly's te compileren in systeemeigen code.
AOT-compilatie
Met de optie AOT-compilatie (op de pagina Packagingeigenschappen) kunt u assemblies vooraf (Ahead-of-Time) compileren. Wanneer deze optie is ingeschakeld, wordt JIT-opstartoverhead (Just-In-Time) geminimaliseerd door assembly's vooraf te compileren vóór runtime. De resulterende systeemeigen code is opgenomen in de APK, samen met de niet-gecompileerde assembly's. Dit resulteert in kortere opstarttijd van toepassingen, maar ten koste van iets grotere APK-grootten.
Voor de AOT-compilatieoptie is een Enterprise-licentie of hoger vereist. AOT-compilatie is alleen beschikbaar wanneer het project is geconfigureerd voor de releasemodus en deze standaard is uitgeschakeld. Zie AOT voor meer informatie over AOT-compilatie.
LLVM Compiler optimaliseren
De LLVM Optimizeing Compiler maakt kleinere en snellere gecompileerde code en converteert AOT-gecompileerde assembly's naar systeemeigen code, maar ten koste van tragere buildtijden. De LLVM-compiler is standaard uitgeschakeld. Als u de LLVM-compiler wilt gebruiken, moet de optie AOT-compilatie eerst zijn ingeschakeld (op de pagina Verpakkingseigenschappen ).
Opmerking
Voor de optie LLVM Compiler optimaliseren is een Enterprise-licentie vereist.
Verpakkingseigenschappen instellen
Verpakkingseigenschappen kunnen worden ingesteld in de sectie Android-opties van projecteigenschappen, zoals wordt weergegeven in de volgende schermopname:
Veel van deze eigenschappen, zoals Gedeelde runtime gebruiken en Snelle implementatie gebruiken , zijn bedoeld voor de foutopsporingsmodus. Wanneer de toepassing echter is geconfigureerd voor de releasemodus, zijn er andere instellingen die bepalen hoe de app is geoptimaliseerd voor de grootte en uitvoeringssnelheid, hoe deze wordt beschermd tegen manipulatie en hoe deze kan worden verpakt om verschillende architecturen en groottebeperkingen te ondersteunen.
Ondersteunde architecturen opgeven
Wanneer u een Xamarin.Android-app voorbereidt voor de release, moet u de CPU-architecturen opgeven die worden ondersteund. Eén APK kan machinecode bevatten ter ondersteuning van meerdere, verschillende architecturen. Zie CPU-architecturen voor meer informatie over het ondersteunen van meerdere CPU-architecturen.
Eén pakket genereren (. APK) per geselecteerde ABI
Wanneer deze optie is ingeschakeld, wordt er één APK gemaakt voor elk van de ondersteunde ABI's (geselecteerd op het tabblad Geavanceerd , zoals beschreven in CPU-architecturen) in plaats van één grote APK voor alle ondersteunde ABI's. Deze optie is alleen beschikbaar wanneer het project is geconfigureerd voor de releasemodus en deze standaard is uitgeschakeld.
Multi-Dex
Wanneer de optie Multi-Dex inschakelen is ingeschakeld, worden Android SDK-hulpprogramma's gebruikt om de limiet voor de 65K-methode van de .dex-bestandsindeling te omzeilen. De beperking van de 65K-methode is gebaseerd op het aantal Java-methoden waarnaar een app verwijst (inclusief de methoden in bibliotheken waarvan de app afhankelijk is) – deze is niet gebaseerd op het aantal methoden dat in de broncode is geschreven. Als een toepassing slechts een paar methoden definieert, maar veel (of grote bibliotheken) gebruikt, is het mogelijk dat de limiet van 65.000.000 wordt overschreden.
Het is mogelijk dat een app niet elke methode gebruikt in elke bibliotheek waarnaar wordt verwezen; Daarom is het mogelijk dat een hulpprogramma zoals ProGuard (zie hierboven) de ongebruikte methoden uit code kan verwijderen. De aanbevolen procedure is om Multi-Dex inschakelen alleen in te schakelen als dat absoluut noodzakelijk is, dat wil bijvoorbeeld dat de app nog steeds verwijst naar meer dan 65.000 Java-methoden, zelfs na het gebruik van ProGuard.
Zie Apps configureren met meer dan 64K-methoden voor meer informatie over Multi-Dex.
Android-app-bundels
App-bundels verschillen van API's omdat ze niet rechtstreeks op een apparaat kunnen worden geïmplementeerd. Het is eerder een formaat dat bedoeld is om samen met al uw gecompileerde code en bronnen te worden geüpload. Nadat u uw ondertekende app-bundel hebt geüpload, beschikt Google Play over alles wat nodig is om de API's van uw toepassing te bouwen en te ondertekenen en aan uw gebruikers te leveren met behulp van Dynamic Delivery.
Als u ondersteuning voor Android-app-bundels wilt inschakelen, moet u de waarde van Android Package Format binnen de opties van uw Android-project kiezen. Voordat u dit doet, moet u ervoor zorgen dat u uw project wijzigt in een Release configuratie omdat app-bundels alleen zijn bedoeld voor releasepakketten.
U kunt nu een app-bundel genereren door de Archive Flow te volgen. Hiermee wordt een app-bundel voor uw toepassing gegenereerd.
Zie Android App Bundles voor meer informatie over Android App Bundles.
Compileren
Nadat alle bovenstaande stappen zijn voltooid, is de app klaar voor compilatie. Selecteer Build Rebuild > Solution om te controleren of deze wordt gebouwd in de releasemodus. Houd er rekening mee dat deze stap nog geen APK produceert.
Het ondertekenen van het app-pakket bespreekt het verpakken en ondertekenen in meer detail.
Archief voor publicatie
Als u het publicatieproces wilt starten, klikt u met de rechtermuisknop op het project in Solution Explorer en selecteert u het contextmenu-item Archief...
Archief... start Archive Manager en begint met het archiveren van de app-bundel, zoals wordt weergegeven in deze schermopname:
Een andere manier om een archief te maken, is door met de rechtermuisknop op de oplossing te klikken in Solution Explorer en Alles archiveren te selecteren..., waarmee de oplossing wordt gebouwd en alle Xamarin-projecten worden gearchiveerd die een archief kunnen genereren:
Zowel Archiveren als Alles archiveren starten automatisch de Archiefbeheerder. Als u de Archiefbeheerder rechtstreeks wilt starten, klikt u op het menu-item Hulpmiddelen > Archiefbeheer...
De archieven van de oplossing op elk gewenst moment door met de rechtermuisknop op het knooppunt Oplossing te klikken en Archieven weergeven te selecteren:
Archiefbeheer
Archive Manager bestaat uit een deelvenster Oplossingslijst, een archievenlijst en een detailvenster:
In de lijst met oplossingen worden alle oplossingen weergegeven met ten minste één gearchiveerd project. De lijst met oplossingen bevat de volgende secties:
- Huidige oplossing : geeft de huidige oplossing weer. Houd er rekening mee dat dit gebied leeg kan zijn als de huidige oplossing geen bestaand archief heeft.
- Alle archieven : geeft alle oplossingen weer die een archief hebben.
- Zoektekstvak (bovenaan): hiermee filtert u de oplossingen in de lijst Alle archieven op basis van de zoekreeks die in het tekstvak is ingevoerd.
In de archievenlijst wordt de lijst met alle archieven voor de geselecteerde oplossing weergegeven. De archievenlijst bevat de volgende secties:
- Naam van geselecteerde oplossing: geeft de naam weer van de oplossing die is geselecteerd in de lijst met oplossingen. Alle informatie die in de archievenlijst wordt weergegeven, verwijst naar deze geselecteerde oplossing.
- Platformfilter : dit veld maakt het mogelijk om archieven te filteren op platformtype (zoals iOS of Android).
- Archiefitems : lijst met archieven voor de geselecteerde oplossing. Elk item in deze lijst bevat de projectnaam, de aanmaakdatum en het platform. Er kan ook aanvullende informatie worden weergegeven, zoals de voortgang wanneer een item wordt gearchiveerd of gepubliceerd.
In het detailvenster wordt aanvullende informatie over elk archief weergegeven. Hiermee kan de gebruiker ook de distributiewerkstroom starten of de map openen waarin de distributie is gemaakt. Met de sectie Opmerkingen maken kunt u buildopmerkingen opnemen in het archief.
Distributie
Wanneer een gearchiveerde versie van de toepassing klaar is om te publiceren, selecteert u het archief in Archive Manager en klikt u op de knop Distribueren... :
In het dialoogvenster Distributiekanaal ziet u informatie over de app, een indicatie van de voortgang van de distributiewerkstroom en een keuze uit distributiekanalen. In de eerste uitvoering worden twee opties weergegeven:
Het is mogelijk om een van de volgende distributiekanalen te kiezen:
Ad-Hoc : slaat een ondertekende APK op schijf op die kan worden sideloaden naar Android-apparaten. Ga door met het ondertekenen van het app-pakket voor meer informatie over het maken van een Android-handtekeningidentiteit, het maken van een nieuw handtekeningcertificaat voor Android-toepassingen en het publiceren van een ad-hocversie van de app op schijf. Dit is een goede manier om een APK te maken voor testen.
Google Play – Publiceert een ondertekende APK naar Google Play. Ga door met publiceren naar Google Play voor meer informatie over het ondertekenen en publiceren van een APK in de Google Play Store.
