Aplikacje mobilne · Publikacja

Publikowanie aplikacji na Androida: APK i AAB

Działająca aplikacja to jeszcze nie koniec pracy. Podstawa programowa wymaga umiejętności przygotowania aplikacji do publikacji w sklepie: ustawienia danych aplikacji, podpisania jej własnym kluczem i zbudowania pliku instalacyjnego (APK) albo paczki dla Google Play (AAB).

około 60 minut
.NET MAUI · Android · dotnet publish · keytool
INF.04.6.2

Po tej lekcji: ustawić ApplicationId i wersje, wygenerować klucz podpisujący, zbudować podpisane APK/AAB w trybie Release oraz zastosować listę kontrolną przed publikacją.

Pakiet do instalacji i pakiet dla sklepu

Przycisk Uruchom w Visual Studio nie jest dystrybucją. Przygotujemy dane aplikacji, klucz podpisu i dwa różne wyniki publikowania bez mylenia APK z AAB.

Najpierw uruchomisz mały ekran. Potem połączysz go z kodem i sprawdzisz konkretne wyniki. Dodatki wykonuj dopiero, gdy wersja podstawowa działa. Quiz i oceniane zadania pozostają w biurku po zalogowaniu.

Laboratorium · ćwiczenie w przeglądarce, do którego odsyłają rozgrzewki na końcu lekcji

1 · Sprawdź w działaniu

Czy to przejdzie do sklepu?

Zmieniaj ustawienia i obserwuj ocenę oraz polecenie dotnet publish. Znajdź kombinacje, które sklep odrzuci: APK dla Google Play, klucz debugowy, niezwiększony numer wersji, zmieniony ApplicationId i klucz w repozytorium.

Najpierw przewidź, potem sprawdź: W modelu publikacji wybierz APK i AAB. Prześledź rolę konfiguracji Release, numeru wersji i podpisu. Symulacja nie tworzy pliku ani klucza.

Większość błędów publikacji to nie kod, a konfiguracja: format, podpis, identyfikator i numer wersji. Model pomaga zobaczyć mechanizm; właściwą aplikację uruchomisz z plików poniżej.

1. Przygotuj miejsce pracy

Pracuj na kopii działającego projektu MAUI z celem net10.0-android. Ta lekcja nie wymaga nowego formularza.
Najpierw uruchom aplikację na skonfigurowanym Androidzie. Samo działanie na Windows nie dowodzi gotowości publikacjiAndroid.
Przygotuj własne dane aplikacji oraz bezpieczny katalog na klucz i pliki haseł, poza repozytorium i materiałami wysyłanymi nauczycielowi.

Co dodajesz, a co podmieniasz?

Stronę dodaj przez Projekt → Dodaj → Nowy element → .NET MAUI ContentPage (XAML). Powstaje para .xaml i .xaml.cs. Dla ContentView wybierz szablon ContentView; dla modeli i serwisów zwykłą klasę. Jeśli plik już istnieje, podmień wskazaną zawartość — nie twórz drugiej klasy o tej samej nazwie.

Plik	Rola w ćwiczeniu
NazwaProjektu.csproj (fragment)	Fragment w istniejącym pliku

Zanim uruchomisz: trzy połączenia

x:Class="MojaAplikacja.NazwaStrony" w XAML musi zgadzać się z namespace MojaAplikacja i nazwą klasy C#. InitializeComponent() tworzy kontrolki opisane w XAML.

x:Name="PoleImie" daje kodowi C# dostęp przez PoleImie.Text. Z kolei Clicked="Zapisz_Clicked" wskazuje metodę o tej nazwie w pliku .xaml.cs. Sam napis przycisku w Text niczego nie podpina.

Gdy dodajesz XAML z obsługą zdarzeń, od razu uzupełnij też odpowiadający C#. Uruchamiaj dopiero po skończeniu oznaczonej pary plików; brakujący handler nie jest błędem środowiska.

Ostatni krok cyklu życia aplikacji

Kod to jeszcze nie produkt

Na egzaminie praktycznym, a tym bardziej w prawdziwej pracy, nie wystarczy kod otwarty w Visual Studio. Potrzebny jest gotowy plik instalacyjny. Proces przygotowania jest identyczny dla małego projektu zaliczeniowego i dla aplikacji w Google Play.

Na egzaminie ten temat pojawia się zwykle jako pytania teoretyczne: różnica APK i AAB, po co podpisywanie, czym jest ApplicationId. Dostęp do konta Google Play nie jest potrzebny, by to zrozumieć.

2 · Dwa formaty

Który plik, kiedy

Format	Opis	Zastosowanie
APK (Android Package)	Plik instalowany bezpośrednio na urządzeniu.	Testy wewnętrzne, wysłanie znajomemu, dystrybucja poza sklepem.
AAB (Android App Bundle)	Format wymagany przez Google Play. Sklep sam generuje APK dopasowane do urządzenia.	Publikacja w sklepie; mniejszy rozmiar pobrania.

Polecenia różnią się jednym parametrem: `-p:AndroidPackageFormats=aab` albo `apk`.

7 · Zanim wyślesz

Checklista przed publikacją

Sprawdź	Dlaczego
Test w trybie Release	Może zachowywać się inaczej niż Debug.
Poprawna nazwa i `ApplicationId`	Zmiana po publikacji tworzy nową aplikację.
Zwiększony `ApplicationVersion`	Sklep odrzuca ten sam lub niższy numer.
Ikona i ekran startowy	Pierwsze wrażenie użytkownika.
Tylko potrzebne uprawnienia	Zbędne uprawnienia budzą nieufność i mogą blokować publikację.
Test na prawdziwym urządzeniu	Emulator nie pokazuje wszystkiego (GPS, aparat).
Bezpieczna kopia klucza	Bez niego nie wydasz aktualizacji.
Materiały dla sklepu	Opis, zrzuty ekranu, polityka prywatności.

Politykę prywatności warto umieć napisać także wtedy, gdy aplikacja nie zbiera żadnych danych.

4. Połącz wygląd z działaniem

Teraz zbuduj docelowy przykład. Pełne pliki poniżej zastępują swoje wcześniejsze wersje. Przeczytaj opis nad kodem i objaśnienia pod nim; potem sprawdź przepływ danych, nie tylko brak czerwonych podkreśleń.

Gdy przykład ma kilka plików zależnych od siebie, najpierw dodaj wszystkie wskazane typy, a potem uruchom całość. Ustaw breakpoint w obsłudze głównego przycisku i prześledź jedną próbę.

Budowa krok po kroku

Fragment pliku .csproj

To fragment do właściwej PropertyGroup, nie zamiennik całego csproj. Zachowaj zależności oraz zasoby i upewnij się, że docelowy framework istnieje.

Cztery wartości, które muszą być poprawne przed publikacją.

NazwaProjektu.csproj (fragment)xml

<PropertyGroup>
  <ApplicationTitle>Moja aplikacja</ApplicationTitle>
  <ApplicationId>pl.bitedu.mojaaplikacja</ApplicationId>
  <ApplicationDisplayVersion>1.0</ApplicationDisplayVersion>
  <ApplicationVersion>1</ApplicationVersion>
  <TargetFrameworks>net10.0-android</TargetFrameworks>
</PropertyGroup>

ApplicationTitle Nazwa widoczna dla użytkownika.
ApplicationId Unikalny identyfikator w formie odwróconej domeny, małymi literami, np. pl.bitedu.mojaaplikacja. Nie zmieniaj go po pierwszej publikacji: sklep uzna to za nową aplikację i utracisz historię instalacji i opinii.
ApplicationDisplayVersion Wersja widoczna dla użytkownika, np. 1.0.
ApplicationVersion Wewnętrzny numer całkowity, który musi rosnąć przy każdej aktualizacji.

Budowa krok po kroku

Tworzenie klucza podpisującego (raz)

Uruchom w terminalu w katalogu projektu. Polecenie tworzy magazyn podpisu; chroń go i zrób bezpieczną kopię, nie wysyłaj pliku ani haseł jako pracy domowej.

Uruchom w terminalu PowerShell, w katalogu projektu, z JDK/keytool dostępnym w PATH. Narzędzie zapyta o hasła i dane certyfikatu. Nie wpisuj rzeczywistych haseł do treści lekcji ani do pliku projektu.

Terminalbash

keytool -genkeypair -v -keystore bitedu-release.keystore -alias bitedu -keyalg RSA -keysize 2048 -validity 10000

-keystore i -alias Nazwa pliku magazynu kluczy i nazwa klucza w nim.
-keyalg RSA -keysize 2048 Algorytm i długość klucza.
-validity 10000 Ważność w dniach (około 27 lat).

Budowa krok po kroku

Budowanie AAB

Jednowierszowe polecenie do PowerShell. Wpisz rzeczywistą nazwę projektu i przygotuj pliki haseł poza repozytorium. AAB nie służy do bezpośredniej instalacji.

Polecenie w jednej linii działa w PowerShell. Podmień NazwaProjektu.csproj. Pliki klucz-haslo.txt i magazyn-haslo.txt zawierają odpowiadające hasła; trzymaj je lokalnie poza repozytorium i nie dołączaj do pracy ucznia. Użycie file: pozwala nie wpisywać hasła dosłownie do polecenia. Dla prawdziwej publikacji zachowaj bezpiecznie keystore i dane podpisu.

Terminalbash

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=file:klucz-haslo.txt -p:AndroidSigningStorePass=file:magazyn-haslo.txt

-f net10.0-android Docelowy framework musi istnieć w projekcie i mieć zainstalowany workloadAndroid.
AndroidPackageFormats aab to pakiet dla sklepu; nie instaluje się go bezpośrednio jak APK.
file:... Wskazuje plik hasła. To nie nazwa samego hasła ani plik keystore. Wymagany jest rzeczywisty build na skonfigurowanym SDK.

Budowa krok po kroku

Budowanie APK

To oddzielne wywołanie dla APK. Po udanym buildzie odszukaj plik w katalogu publikacji, zamiast uznawać samo zakończenie polecenia za test instalacji.

Terminalbash

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=file:klucz-haslo.txt -p:AndroidSigningStorePass=file:magazyn-haslo.txt

-f net10.0-android Docelowy framework musi istnieć w projekcie i mieć zainstalowany workloadAndroid.
AndroidPackageFormats aab to pakiet dla sklepu; nie instaluje się go bezpośrednio jak APK.
file:... Wskazuje plik hasła. To nie nazwa samego hasła ani plik keystore. Wymagany jest rzeczywisty build na skonfigurowanym SDK.

5. Odbiór: czy naprawdę działa?

Wykonaj próby w swojej aplikacji, nie tylko w modelu na stronie. Zaznaczaj dopiero po sprawdzeniu wyniku. Funkcje urządzenia wymagają testu na właściwej platformie.

Sprawdź ApplicationId i rosnący ApplicationVersion. Zrób kopię projektu przed edycją csproj.
Zbuduj APK w skonfigurowanym środowiskuAndroid, znajdź plik wynikowy i przetestuj instalację na własnym urządzeniu.
Zbuduj AAB oddzielnie. Nie próbuj otwierać go jak APK; to format przekazywany do procesu dystrybucji sklepu.

8 · Czego unikać

Cztery błędy przy publikacji

Klucz debugowy zamiast własnego

Tak nie

# podpis domyślnym kluczem debugowym

Google Play odrzuci aplikację.

Tak

keytool -genkeypair ... -keystore bitedu-release.keystore

Do dystrybucji potrzebny jest własny klucz.

Zmiana ApplicationId między wersjami

Tak nie

<ApplicationId>pl.bitedu.nowaaplikacja</ApplicationId>

Sklep i Android traktują to jako zupełnie inną aplikację.

Tak

<ApplicationId>pl.bitedu.mojaaplikacja</ApplicationId>

Identyfikator jest stały po pierwszej publikacji.

Ten sam ApplicationVersion

Tak nie

<ApplicationVersion>1</ApplicationVersion>   <!-- było już 1 -->

Sklep odrzuci przesłanie aktualizacji.

Tak

<ApplicationVersion>2</ApplicationVersion>

Numer musi rosnąć przy każdej aktualizacji.

Keystore i hasła w publicznym repozytorium

Tak nie

git add bitedu-release.keystore

Każdy, kto zobaczy historię, może podpisywać aplikacje Twoim kluczem.

Tak

# plik poza repozytorium, dopisany do .gitignore

Klucz i hasła trzymamy w prywatnym, bezpiecznym miejscu.

Ćwiczenie z pomocą · samodzielna praca

6. Mała zmiana, którą zrobisz samodzielnie

Przygotuj następną wersję aplikacji bez zmiany jej identyfikatora.

Oczekiwany rezultat

Przygotuj następną wersję aplikacji bez zmiany jej identyfikatora.
Dotychczasowe działanie ma pozostać poprawne.

Potrzebujesz pomocy? Rozwiązuj krok po kroku.

Krok 1 — pokaż podpowiedź

Zwiększ ApplicationVersion jako liczbę całkowitą.

Krok 2 — pokaż podpowiedź

Zmień widoczne ApplicationDisplayVersion, np.1.0 na1.1.

Krok 3 — pokaż podpowiedź

Zachowaj ApplicationId i właściwy klucz podpisu; sprawdź aktualizację tej samej instalacji.

Otwórz tylko tyle podpowiedzi, ile potrzebujesz. Po każdym kroku wróć do zadania i sprawdź wynik.

9 · Sprawdź się

APK, AAB czy poprawka?

Cztery sytuacje.

Podsumowanie

Co warto zapamiętać

APK instaluje się bezpośrednio (testy), AAB jest wymagany przez Google Play.
ApplicationId ustawiasz raz, a ApplicationVersion zwiększasz przy każdej aktualizacji.
Aplikację podpisujesz własnym kluczem release z keytool, nigdy debugowym. Klucz przechowuj bezpiecznie, poza repozytorium.
Budujesz dotnet publish -c Release z parametrami podpisu. Różnica APK i AAB to jeden parametr.
Przed publikacją przejdź listę kontrolną, w tym test na prawdziwym urządzeniu.

Dalej na swoim koncie

Rozgrzewki, quiz i zadania są w biurku ucznia.

Teoria jest otwarta dla wszystkich. Żeby rozwiązywać zadania, zapisywać szkice i widzieć swój postęp, zaloguj się.

Zaloguj się →

Źródła i dalsza nauka