Not
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
När ett program har kodats och testats är det nödvändigt att förbereda ett paket för distribution. Den första uppgiften när du förbereder det här paketet är att skapa programmet för lansering, vilket främst innebär att vissa programattribut anges.
Använd följande steg för att skapa appen för lansering:
Ange programikonen – Varje Xamarin.Android-program ska ha en programikon angiven. Även om det inte är tekniskt nödvändigt, kräver vissa marknader, till exempel Google Play, det.
Version av programmet – Det här steget innebär att initiera eller uppdatera versionsinformationen. Detta är viktigt för framtida programuppdateringar och för att säkerställa att användarna är medvetna om vilken version av programmet de har installerat.
Minska APK – Storleken på den slutliga APK:en kan minskas avsevärt med hjälp av Xamarin.Android-länkaren på den hanterade koden och ProGuard på Java-bytekoden.
Skydda programmet – Förhindra användare eller angripare från att felsöka, manipulera eller bakåtkompilera programmet genom att inaktivera felsökning, dölja den hanterade koden, lägga till anti-felsökning och antimanipulering och använda intern kompilering.
Ange paketeringsegenskaper – Paketeringsegenskaper styr skapandet av Android-programpaketet (APK). Det här steget optimerar APK:t, skyddar dess tillgångar och modulariserar paketeringen efter behov. Dessutom kan du ge användarna ett Android App-paket som är optimerat för deras enheter.
Kompilera – Det här steget kompilerar koden och tillgångarna för att verifiera att den skapas i versionsläge.
Arkiv för publicering – Det här steget skapar appen och placerar den i ett arkiv för signering och publicering.
Vart och ett av dessa steg beskrivs nedan i detalj.
Ange programikonen
Vi rekommenderar starkt att varje Xamarin.Android-program anger en programikon. Vissa programmarknadsplatser tillåter inte att ett Android-program publiceras utan ett. Egenskapen Icon för Application attributet används för att ange programikonen för ett Xamarin.Android-projekt.
I Visual Studio 2017 och senare anger du programikonen via androidmanifestet i projektets egenskaper, enligt följande skärmbild:
I de här exemplen @drawable/icon refererar till en ikonfil som finns i Resurser/ritabar/icon.png (observera att .png-tillägget inte ingår i resursnamnet). Det här attributet kan också deklareras i filen Properties\AssemblyInfo.cs, enligt följande exempelfragment:
[assembly: Application(Icon = "@drawable/icon")]
Normalt deklareras using Android.App överst i AssemblyInfo.cs (namnområdet för Application attributet är Android.App); men däremot kan du behöva lägga till det här using uttalandet om det inte redan finns.
Version av programmet
Versionshantering är viktigt för underhåll och distribution av Android-program. Utan någon form av versionshantering på plats är det svårt att avgöra om eller hur ett program ska uppdateras. För att hjälpa till med versionshantering identifierar Android två olika typer av information:
Versionsnummer – ett heltalsvärde (som används internt av Android och programmet) som representerar versionen av programmet. De flesta program börjar med det här värdet inställt på 1 och sedan ökas det med varje version. Det här värdet har ingen relation eller tillhörighet med versionsnamnets attribut (se nedan). Program och publiceringstjänster bör inte visa det här värdet för användarna. Det här värdet lagras i filenAndroidManifest.xml som
android:versionCode.Versionsnamn – en sträng som endast används för att kommunicera information till användaren om programmets version (som installerat på en specifik enhet). Versionsnamnet är avsett att visas för användare eller i Google Play. Den här strängen används inte internt av Android. Versionsnamnet kan vara valfritt strängvärde som hjälper en användare att identifiera den version som är installerad på deras enhet. Det här värdet lagras i filenAndroidManifest.xml som
android:versionName.
I Visual Studio kan dessa värden anges i avsnittet Android-manifest i projektegenskaper, enligt följande skärmbild:
Krymp APK-fil
Xamarin.Android-API:er kan göras mindre genom en kombination av Xamarin.Android-länkaren, som tar bort onödig hanterad kod och ProGuard-verktyget från Android SDK, vilket tar bort oanvänd Java-bytekod. Byggprocessen använder först Xamarin.Android-länkaren för att optimera appen på C#-nivå (hanterad kod) och använder sedan ProGuard (om den är aktiverad) för att optimera APK på Java-bytekodsnivå.
Konfigurera Länkare
Versionsläget inaktiverar den delade körningen och aktiverar länkning så att programmet endast skickar de delar av Xamarin.Android som krävs vid körning. Länkaren i Xamarin.Android använder statisk analys för att avgöra vilka sammansättningar, typer och typmedlemmar som används eller refereras av ett Xamarin.Android-program. Länkaren tar sedan bort alla oanvända sammansättningar, typer och medlemmar som inte används (eller refereras till). Detta kan leda till en betydande minskning av paketstorleken. Tänk till exempel på HelloWorld-exemplet , som har en 83% minskning av den slutliga storleken på dess APK:
Konfiguration: Ingen – Xamarin.Android 4.2.5 Storlek = 17,4 MB.
Konfiguration: Endast SDK-sammansättningar – Xamarin.Android 4.2.5 Storlek = 3,0 MB.
Ange länkalternativ via avsnittet Android-alternativ i projektets egenskaper:
Menyn Länkning rullgardinsmeny innehåller följande alternativ för att styra länkaren:
Ingen – Detta stänger av länkaren; ingen länkning utförs.
Endast SDK-sammansättningar – Detta länkar bara de sammansättningar som krävs av Xamarin.Android. Andra komponenter länkas inte.
Sdk och användarsammansättningar – Detta länkar alla sammansättningar som krävs av programmet och inte bara de som krävs av Xamarin.Android.
Länkning kan ge vissa oavsiktliga biverkningar, så det är viktigt att ett program testas på nytt i versionsläge på en fysisk enhet.
ProGuard
ProGuard är ett Android SDK-verktyg som länkar och fördunklar Java-kod. ProGuard används normalt för att skapa mindre program genom att minska fotavtrycket för stora bibliotek (till exempel Google Play Services) i din APK. ProGuard tar bort oanvänd Java-bytekod, vilket gör den resulterande appen mindre. Om du till exempel använder ProGuard på små Xamarin.Android-appar uppnås vanligtvis ungefär 24% storleksminskning – om du använder ProGuard på större appar med flera biblioteksberoenden får du vanligtvis en ännu större storleksminskning.
ProGuard är inte ett alternativ till Xamarin.Android-länkaren. Xamarin.Android-länkaren länkar hanterad kod, medan ProGuard länkar Java-bytekod. Byggprocessen använder först Xamarin.Android-länkaren för att optimera den hanterade koden (C#) i appen, och sedan använder den senare ProGuard (om den är aktiverad) för att optimera APK på Java-bytekodsnivå.
När Aktivera ProGuard är markerat kör Xamarin.Android ProGuard-verktyget på den resulterande APK:en. En ProGuard-konfigurationsfil genereras och används av ProGuard vid byggtiden. Xamarin.Android har också stöd för anpassade ProguardConfiguration-byggåtgärder . Du kan lägga till en anpassad ProGuard-konfigurationsfil i projektet, högerklicka på den och välja den som en byggåtgärd som du ser i det här exemplet:
ProGuard är inaktiverat som standard. Alternativet Aktivera ProGuard är endast tillgängligt när projektet är inställt på Versionsläge . Alla ProGuard-byggåtgärder ignoreras om inte Aktivera ProGuard är markerat. Xamarin.Android ProGuard-konfigurationen fördunklar inte APK och det går inte att aktivera fördunkling, även med anpassade konfigurationsfiler. Om du vill använda obfuskering läser du Programskydd med Dotfuscator.
Mer detaljerad information om hur du använder ProGuard-verktyget finns i ProGuard.
Skydda programmet
Inaktivera felsökning
Under utvecklingen av ett Android-program utförs felsökning med hjälp av Java Debug Wire Protocol (JDWP). Det här är en teknik som gör det möjligt för verktyg som adb att kommunicera med en JVM för felsökning. JDWP är aktiverat som standard för felsökningsversioner av ett Xamarin.Android-program. Även om JDWP är viktigt under utvecklingen kan det utgöra ett säkerhetsproblem för släppta program.
Viktigt!
Inaktivera alltid felsökningstillståndet i ett släppt program eftersom det är möjligt (via JDWP) att få fullständig åtkomst till Java-processen och köra godtycklig kod i programmets kontext om det här felsökningstillståndet inte är inaktiverat.
Android-manifestet innehåller attributet android:debuggable, vilket styr om programmet kan debuggas eller inte. Det anses vara en bra idé att ange android:debuggable attributet till false. Det enklaste sättet att göra detta är genom att lägga till en villkorsstyrd kompileringssats i AssemblyInfo.cs:
#if DEBUG
[assembly: Application(Debuggable=true)]
#else
[assembly: Application(Debuggable=false)]
#endif
Observera att felsökningsversioner automatiskt anger vissa behörigheter för att göra felsökning enklare (till exempel Internet och ReadExternalStorage). Utgåvor använder dock endast de behörigheter som du uttryckligen konfigurerar. Om du upptäcker att om du växlar till versionsversionen förlorar appen en behörighet som var tillgänglig i felsökningsversionen kontrollerar du att du uttryckligen har aktiverat den här behörigheten i listan Nödvändiga behörigheter enligt beskrivningen i Behörigheter.
Programskydd med Dotfuscator
Även om felsökning är inaktiverat är det fortfarande möjligt för angripare att paketera om ett program, lägga till eller ta bort konfigurationsalternativ eller behörigheter. Detta gör det möjligt för dem att bakåtutveckla, felsöka eller manipulera programmet. Dotfuscator Community Edition (CE) kan användas för att obfuskera hanterad kod och injicera kod för att upptäcka körningssäkerhetstillstånd i en Xamarin.Android-app under byggprocessen för att upptäcka och reagera om appen körs på en enhet med root.
Dotfuscator CE ingår i Visual Studio 2017. Om du vill använda Dotfuscator klickar du på Verktyg > Förebyggande skydd – Dotfuscator.
Information om hur du konfigurerar Dotfuscator CE finns i Använda Dotfuscator Community Edition med Xamarin. När den har konfigurerats skyddar Dotfuscator CE automatiskt varje version som skapas.
Samla samlingar till nativ kod
När det här alternativet är aktiverat paketeras sammansättningar i ett inbyggt delat bibliotek. Detta gör att sammansättningar kan komprimeras, vilket tillåter mindre .apk filer. Sammansättningskomprimering ger också en minimal form av fördunkling; sådan fördunkling bör inte åberopas.
Det här alternativet kräver en Enterprise-licens och är endast tillgängligt när Snabb distribution är inaktiverad. Sammanställ sammansättningar till inbyggd kod är inaktiverad som standard.
Observera att alternativet Bundle into Native Codeinte innebär att sammansättningarna kompileras till intern kod. Det går inte att använda AOT-kompilering för att kompilera sammansättningar till intern kod.
AOT-kompilering
Med AOT-kompileringsalternativet (på sidan Paketeringsegenskaper ) kan du kompilera sammansättningar i förväg (AOT). När det här alternativet är aktiverat minimeras JIT-startkostnaderna (Just In Time) genom att förkompilera samlingar innan körning. Den resulterande interna koden ingår i APK tillsammans med de okompilerade sammansättningarna. Detta resulterar i kortare starttid för program, men på bekostnad av något större APK-storlekar.
Alternativet AOT-kompilering kräver en Enterprise-licens eller högre. AOT-kompilering är endast tillgängligt när projektet har konfigurerats för versionsläge och inaktiveras som standard. Mer information om AOT-kompilering finns i AOT.
LLVM-optimering av kompilator
LLVM Optimizeing Compiler skapar mindre och snabbare kompilerad kod och konverterar AOT-kompilerade sammansättningar till intern kod, men på bekostnad av långsammare byggtider. LLVM-kompilatorn är inaktiverad som standard. Om du vill använda LLVM-kompilatorn måste alternativet AOT-kompilering först aktiveras (på sidan Paketeringsegenskaper ).
Anmärkning
Alternativet LLVM-optimering av kompilator kräver en Enterprise-licens.
Ange paketeringsegenskaper
Paketeringsegenskaper kan anges i avsnittet Android-alternativ i projektegenskaper, enligt följande skärmbild:
Många av dessa egenskaper, till exempel Använd delad körning och Använd snabb distribution , är avsedda för felsökningsläge. Men när programmet har konfigurerats för versionsläge finns det andra inställningar som avgör hur appen är optimerad för storlek och körningshastighet, hur den skyddas från manipulering och hur den kan paketeras för att stödja olika arkitekturer och storleksbegränsningar.
Ange arkitekturer som stöds
När du förbereder en Xamarin.Android-app för lansering är det nödvändigt att ange de CPU-arkitekturer som stöds. En enda APK kan innehålla maskinkod för att stödja flera olika arkitekturer. Mer information om stöd för flera CPU-arkitekturer finns i CPU-arkitekturer .
Generera ett paket (. APK) per vald ABI
När det här alternativet är aktiverat skapas en APK för var och en av de ABI:er som stöds (väljs på fliken Avancerat , enligt beskrivningen i CPU-arkitekturer) i stället för en enda, stor APK för alla ABI:er som stöds. Det här alternativet är endast tillgängligt när projektet har konfigurerats för versionsläge och är inaktiverat som standard.
Multi-Dex
När alternativet Aktivera Multi-Dex är aktiverat används Android SDK-verktyg för att kringgå 65K-metodgränsen för filformatet .dex . 65K-metodbegränsningen baseras på antalet Java-metoder som en app refererar till (inklusive de i alla bibliotek som appen är beroende av) – den baseras inte på antalet metoder som skrivs i källkoden. Om ett program bara definierar några metoder men använder många (eller stora bibliotek) är det möjligt att gränsen på 65 000 överskrids.
Det är möjligt att en app inte använder varje metod i varje bibliotek som refereras. Därför är det möjligt att ett verktyg som ProGuard (se ovan) kan ta bort de oanvända metoderna från koden. Bästa praxis är att aktivera Aktivera Multi-Dex endast om det är absolut nödvändigt, dvs. appen refererar fortfarande till mer än 65 000 Java-metoder även efter att ha använt ProGuard.
Mer information om Multi-Dex finns i Konfigurera appar med över 64 000 metoder.
Android-apppaket
Apppaket skiljer sig från APK:er eftersom de inte kan distribueras direkt till en enhet. I stället är det ett format som är avsett att laddas upp med all kompilerad kod och alla resurser. När du har laddat upp ditt signerade apppaket har Google Play allt som behövs för att skapa och signera applikationens APK:er och leverera dem till dina användare med dynamisk leverans.
Om du vill aktivera stöd för Android-apppaket måste du välja värdet för androidpaketformategenskapenbundle i dina Android-projektalternativ. Innan du gör detta måste du ändra projektet till en Release konfiguration eftersom apppaket endast är avsedda för versionspaket.
Du kan nu generera ett apppaket genom att följa arkivflödet. Detta genererar ett apppaket för ditt program.
Mer information om Android App-paket finns i Android App-paket.
Kompilera
När alla ovanstående steg har slutförts är appen redo för kompilering. Välj Bygg > Återskapa lösning för att kontrollera att den byggs framgångsrikt i Release-läge. Observera att det här steget ännu inte genererar någon APK.
Signering av Apppaket diskuterar paketering och signering mer detaljerat.
Arkiv för publicering
Om du vill påbörja publiceringsprocessen högerklickar du på projektet i Solution Explorer och väljer snabbmenyalternativet Arkiv... :
Arkiv... startar Arkivhanteraren och påbörjar arkiveringen av apppaketet enligt den här skärmbilden:
Ett annat sätt att skapa ett arkiv är att högerklicka på lösningen i Solution Explorer och välja Arkivera alla..., som skapar lösningen och arkiverar alla Xamarin-projekt som kan generera ett arkiv:
Både Arkiv och Arkiv Alla startar automatiskt Arkivhanteraren. Om du vill starta Arkivhanteraren direkt klickar du på menyalternativet Verktyg > arkivhanterare... :
Lösningens arkiv när som helst genom att högerklicka på noden Lösning och välja Visa arkiv:
Arkivhanteraren
Arkivhanteraren består av en lösningslista, en arkivlista och en informationspanel:
Lösningslistan visar alla lösningar som har minst ett arkiverat projekt. Lösningslistan innehåller följande avsnitt:
- Aktuell lösning – Visar den aktuella lösningen. Observera att det här området kan vara tomt om den aktuella lösningen inte har något befintligt arkiv.
- Alla arkiv – Visar alla lösningar som har ett arkiv.
- Sök i textrutan (överst) – Filtrerar lösningarna i listan Alla arkiv enligt söksträngen som anges i textrutan.
Arkivlistan visar listan över alla arkiv för den valda lösningen. Arkivlistan innehåller följande avsnitt:
- Valt lösningsnamn – Visar namnet på den lösning som valts i lösningslistan. All information som visas i arkivlistan refererar till den här valda lösningen.
- Plattformsfilter – Det här fältet gör det möjligt att filtrera arkiv efter plattformstyp (till exempel iOS eller Android).
- Arkivobjekt – Lista över arkiv för den valda lösningen. Varje objekt i den här listan innehåller projektnamn, skapandedatum och plattform. Den kan också visa ytterligare information, till exempel förloppet när ett objekt arkiveras eller publiceras.
Informationspanelen visar ytterligare information om varje arkiv. Det gör också att användaren kan starta distributionsarbetsflödet eller öppna mappen där distributionen har skapats. Avsnittet Skapa kommentarer gör det möjligt att inkludera kompileringskommentar i arkivet.
Fördelning
När en arkiverad version av programmet är redo att publiceras väljer du arkivet i Arkivhanteraren och klickar på knappen Distribuera... :
Dialogrutan Distributionskanal visar information om appen, en indikation på distributionsarbetsflödets förlopp och ett urval av distributionskanaler. På den första körningen visas två alternativ:
Du kan välja någon av följande distributionskanaler:
Ad-Hoc – Sparar en signerad APK på disk som kan läsas in separat till Android-enheter. Fortsätt att signera apppaketet för att lära dig hur du skapar en Android-signeringsidentitet, skapar ett nytt signeringscertifikat för Android-program och publicerar en ad hoc-version av appen på disken. Det här är ett bra sätt att skapa en APK för testning.
Google Play – Publicerar en signerad APK till Google Play. Fortsätt till Publicering på Google Play för att lära dig hur du signerar och publicerar en APK i Google Play-butiken.
