Lekcja 26. Publikowanie aplikacji .NET MAUI na Androida — APK i AAB
Trudny / egzaminacyjnyPo co się tego uczymy?
Napisanie działającej aplikacji to nie koniec pracy — podstawa programowa INF.04.6 wprost wymaga umiejętności "przygotowania aplikacji do publikacji w sklepie". Ta lekcja pokazuje ostatni krok cyklu życia aplikacji mobilnej: przygotowanie danych aplikacji, podpisanie jej cyfrowym kluczem, i zbudowanie plików gotowych do instalacji testowej (APK) albo publikacji w Google Play (AAB).
Teoria
APK czy AAB — dwa różne formaty wynikowe. APK (Android Package) to plik instalowany BEZPOŚREDNIO na urządzeniu — przydatny do testów wewnętrznych i dystrybucji POZA sklepem Google Play (np. wysłanie znajomemu do zainstalowania ręcznie). AAB (Android App Bundle) to format WYMAGANY przez Google Play do publikacji — Google Play samo generuje z niego zoptymalizowane pliki APK dopasowane do konkretnego urządzenia pobierającego aplikację (mniejszy rozmiar pobrania dla użytkownika końcowego).
Dane aplikacji w pliku projektu (.csproj). Przed publikacją trzeba ustawić poprawne wartości: ApplicationTitle (nazwa widoczna dla użytkownika), ApplicationId (UNIKALNY identyfikator aplikacji w formacie odwróconej domeny, np. pl.bitedu.mojaaplikacja — zawsze małymi literami), ApplicationDisplayVersion (wersja widoczna dla użytkownika, np. "1.0"), ApplicationVersion (wewnętrzny numer wersji, liczba całkowita, MUSI być zwiększana przy każdej kolejnej publikacji aktualizacji). Krytyczna zasada: ApplicationId nie powinien być zmieniany PO pierwszej publikacji — zmiana identyfikatora sprawia, że Google Play traktuje to jako CAŁKOWICIE NOWĄ aplikację, tracąc historię instalacji, opinii i aktualizacji.
Podpisywanie aplikacji (klucz release). Android wymaga, żeby każda aplikacja przeznaczona do dystrybucji była podpisana cyfrowym kluczem — to potwierdza tożsamość twórcy aplikacji i pozwala systemowi zweryfikować, że aktualizacja pochodzi od tego samego wydawcy co oryginalna aplikacja. Klucz tworzy się RAZ, standardowym narzędziem keytool (część zestawu narzędzi Javy/Androida), i przechowuje w BEZPIECZNYM miejscu razem z hasłem — ten sam klucz jest potrzebny do podpisywania WSZYSTKICH przyszłych aktualizacji tej samej aplikacji; zgubienie klucza oznacza brak możliwości opublikowania jakiejkolwiek aktualizacji pod tym samym identyfikatorem aplikacji.
Budowanie w trybie Release. Polecenie dotnet publish z parametrem -c Release (konfiguracja Release, a nie domyślna Debug używana podczas programowania) tworzy zoptymalizowaną, gotową do dystrybucji wersję aplikacji. Parametry -p:AndroidPackageFormats (apk albo aab) oraz -p:AndroidKeyStore=true wraz z danymi klucza (AndroidSigningKeyStore, AndroidSigningKeyAlias, hasła) sterują formatem wynikowym i podpisywaniem. Gotowe pliki trafiają zwykle do katalogu bin/Release/[framework]/publish/.
Checklista przed publikacją obejmuje znacznie więcej niż sam plik APK/AAB: przetestowanie w trybie Release (może zachowywać się nieco inaczej niż Debug), poprawność nazwy i identyfikatora, zwiększony numer wersji, przygotowaną ikonę i ekran startowy, ograniczone TYLKO do faktycznie potrzebnych uprawnienia, przetestowanie na prawdziwym urządzeniu fizycznym (nie tylko emulatorze), bezpieczną kopię klucza podpisującego, oraz materiały wymagane przez sklep (opis, zrzuty ekranu, polityka prywatności).
Schemat
Projekt .csproj
│
│ ApplicationId, ApplicationDisplayVersion, ApplicationVersion (++)
▼
keytool -genkeypair → bitedu-release.keystore (RAZ, bezpiecznie przechowywany)
│
▼
dotnet publish -c Release -p:AndroidPackageFormats=aab|apk
-p:AndroidKeyStore=true -p:AndroidSigningKeyStore=... (hasła)
│
├── AndroidPackageFormats=aab ──► plik .aab → Google Play Console
│
└── AndroidPackageFormats=apk ──► plik .apk → instalacja testowa
bezpośrednio na urządzeniu
│
▼
bin/Release/net10.0-android/publish/ (katalog wynikowy)
│
▼
Checklista: wersja, ikona, uprawnienia, test na fizycznym urządzeniu,
kopia klucza, opis + zrzuty ekranu + polityka prywatności
Przykład z życia
Uczniowski projekt zaliczeniowy z INF.04 — mała, kompletna aplikacja mobilna — na etapie egzaminu praktycznego wymaga właśnie takiego kroku: przygotowania gotowego, działającego pliku instalacyjnego, a nie tylko kodu źródłowego otwartego w Visual Studio. To samo dotyczy każdej prawdziwej aplikacji trafiającej na Google Play — proces jest identyczny niezależnie od skali projektu.
Fragment pliku .csproj
<!-- Fragment pliku .csproj -->
<PropertyGroup>
<ApplicationTitle>Moja aplikacja</ApplicationTitle>
<ApplicationId>pl.bitedu.mojaaplikacja</ApplicationId>
<ApplicationDisplayVersion>1.0</ApplicationDisplayVersion>
<ApplicationVersion>1</ApplicationVersion>
<TargetFrameworks>net10.0-android</TargetFrameworks>
</PropertyGroup>Terminal — utworzenie klucza i publikacja AAB/APK
# Krok 1: utworzenie klucza podpisującego (RAZ, przechowywany bezpiecznie)
keytool -genkeypair -v
-keystore bitedu-release.keystore
-alias bitedu
-keyalg RSA
-keysize 2048
-validity 10000
# ---------------------------------------------------------------------
# Krok 2: publikacja AAB do Google Play
dotnet publish NazwaProjektu.csproj
-f net10.0-android
-c Release
-p:AndroidPackageFormats=aab
-p:AndroidKeyStore=true
-p:AndroidSigningKeyStore=bitedu-release.keystore
-p:AndroidSigningKeyAlias=bitedu
-p:AndroidSigningKeyPass=HASLO_KLUCZA
-p:AndroidSigningStorePass=HASLO_MAGAZYNU
# ---------------------------------------------------------------------
# Krok 3: publikacja APK do instalacji testowej
dotnet publish NazwaProjektu.csproj
-f net10.0-android
-c Release
-p:AndroidPackageFormats=apk
-p:AndroidKeyStore=true
-p:AndroidSigningKeyStore=bitedu-release.keystore
-p:AndroidSigningKeyAlias=bitedu
-p:AndroidSigningKeyPass=HASLO_KLUCZA
-p:AndroidSigningStorePass=HASLO_MAGAZYNU
# Pliki wynikowe: bin/Release/net10.0-android/publish/Komentarz i wyjaśnienie kodu
Zwróć uwagę, że polecenia dotnet publish dla AAB i APK różnią się TYLKO jednym parametrem: -p:AndroidPackageFormats=aab kontra =apk — cała reszta konfiguracji (framework, tryb Release, dane podpisywania) pozostaje identyczna. To pokazuje, że wybór formatu wyjściowego to kwestia PRZEZNACZENIA builda (sklep vs. test bezpośredni), a nie innego procesu budowania.
Te same dane logowania klucza (AndroidSigningKeyStore, AndroidSigningKeyAlias, hasła) MUSZĄ być identyczne przy KAŻDEJ kolejnej publikacji aktualizacji tej samej aplikacji — Android sprawdza, czy nowa wersja jest podpisana TYM SAMYM kluczem co poprzednia, i odrzuci aktualizację podpisaną innym kluczem.
Ćwiczenie samodzielne
Przygotuj dowolny prosty projekt MAUI z tego działu, ustaw poprawny ApplicationId (np. pl.twojaszkola.twojenazwisko.projektname) i numer wersji, wygeneruj własny klucz testowy przez keytool, i zbuduj plik APK w trybie Release — sprawdź, czy plik faktycznie powstał w katalogu wynikowym i czy da się go zainstalować na emulatorze albo prawdziwym urządzeniu.
Zadania do pracy własnej
Przygotuj checklistę (na podstawie tej lekcji) w formie listy kontrolnej dla WŁASNEGO projektu zaliczeniowego — z odhaczonymi punktami, które już spełniasz, i zaznaczonymi tymi, których jeszcze brakuje.
Zbuduj TESTOWY plik APK swojego projektu w trybie Release i zainstaluj go na emulatorze (albo prawdziwym telefonie, jeśli masz taką możliwość) — porównaj, czy aplikacja w trybie Release zachowuje się identycznie jak w trybie Debug podczas wcześniejszego programowania.
Przygotuj kompletny "pakiet publikacyjny" dla swojego projektu zaliczeniowego: gotowy plik AAB podpisany własnym kluczem, krótki opis aplikacji (jak dla sklepu Google Play), listę zrzutów ekranu do przygotowania, oraz szkic prostej polityki prywatności (nawet jeśli aplikacja nie zbiera żadnych danych, warto umieć napisać, że tak właśnie jest).
Typowe błędy
Użycie domyślnego klucza DEBUGOWEGO zamiast własnego klucza Release — Google Play odrzuci aplikację podpisaną kluczem debugowym; to musi być własny, wygenerowany klucz przeznaczony do dystrybucji.
Zmiana ApplicationId między kolejnymi wersjami aplikacji — Google Play (i sam Android) traktuje to jako całkowicie inną aplikację, tracąc powiązanie z poprzednimi wersjami, opiniami i historią instalacji.
Brak zwiększenia numeru ApplicationVersion przed kolejną publikacją — sklep odrzuci przesłanie aktualizacji z tym samym (albo niższym) numerem wersji co poprzednio opublikowana.
Umieszczenie pliku keystore albo haseł w publicznym repozytorium kodu (np. GitHub) — to poważny błąd bezpieczeństwa; klucz podpisujący i hasła powinny być przechowywane w bezpiecznym, prywatnym miejscu, NIGDY w historii kontrolowanej wersjami razem z kodem źródłowym.
Nawiązanie do egzaminu zawodowego
To bezpośrednia realizacja końcowego wymagania INF.04.6.2 "przygotowanie do publikacji w sklepie" — ostatni etap cyklu życia aplikacji mobilnej, domykający dział razem z wcześniejszym uruchamianiem aplikacji na emulatorze/urządzeniu. Na egzaminie zawodowym ten temat pojawia się zwykle w formie pytań teoretycznych (różnica APK/AAB, po co podpisywanie, co to ApplicationId), rzadziej jako zadanie praktyczne wymagające faktycznego dostępu do konta Google Play.