Od 27 marca 2025 r. zalecamy używanie android-latest-release zamiast aosp-main do kompilowania i wspołtworzenia AOSP. Więcej informacji znajdziesz w artykule o zmianach w AOSP.
Zadbaj o dobrą organizację dzięki kolekcji
Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.
Flagi wdrażania funkcji są używane przez Google w celu zapewnienia stabilnych gałęzi kodu. Te flagi są też wymagane w przypadku niektórych typów wkładów do AOSP. Zanim wdrożysz oznaczenie funkcji, sprawdź, czy jest ono konieczne w przypadku wprowadzanej zmiany. Jeśli flaga jest potrzebna, określ jej typ.
Określanie użycia flagi
Aby określić, kiedy użyć flagi uruchomienia funkcji, postępuj zgodnie z tymi wskazówkami:
Jeśli wprowadzasz zmianę, która może spowodować niestabilność kodu źródłowego AOSP, np. dodajesz nową funkcję lub naprawiasz szczególnie złożony błąd, użyj flagi uruchomienia funkcji.
Jeśli natomiast wprowadzasz zmianę kodu, która nie powinna powodować niestabilności bazy kodu źródłowego (np. modyfikujesz komentarze), nie musisz używać flagi uruchomienia funkcji.
Określanie typu flagi
Istnieją 2 typy flag: flagi aconfig i flagi kompilacji.
Flagi aconfig
Flagi aconfig służą do oddzielania wykonywania nieopublikowanego kodu od publikowanego kodu podczas procesu testowania i publikowania. Flagi aconfig mogą mieć uprawnienia tylko do odczytu lub odczytu i zapisu:
Flagi aconfig z dostępem do odczytu i zapisu to zmienne logiczne, które możesz włączyć (ustawić na true) lub wyłączyć (ustawić na false) w czasie wykonywania. Użyj flagi odczytu i zapisu, aby przetestować i opublikować zmiany bez wpływu na stabilność gałęzi głównej.
Flagi aconfig tylko do odczytu to stałe logiczne, których nie można zmienić w czasie wykonywania. W przypadku stabilnego kodu, który jest gotowy do wydania, możesz przekształcić flagi aconfig do odczytu i zapisu w flagi aconfig tylko do odczytu.
Dodatkowo w zależności od używanego kompilatora, gdy używana jest flaga tylko do odczytu, kod, który nie jest wykonywany, może zostać wykluczony z kompilacji. Dlatego możesz użyć flag tylko do odczytu, aby ukryć kod, który nie jest gotowy do wydania.
Flagi kompilacji
Flagi kompilacji to stałe (ciągi znaków) definiowane na etapie kompilacji, których nie można zmieniać w czasie wykonywania. Używaj tych flag w sytuacjach, w których nie możesz użyć flag aconfig, np.:
Masz skompilowany lub wstępnie utworzony fragment kodu, który chcesz uwzględnić w kompilacji.
Chcesz wprowadzić zmiany w systemie budowania.
Chcesz umieścić flagi wokół zależności, aby zarządzać rozmiarem kodu.
Treść strony i umieszczone na niej fragmenty kodu podlegają licencjom opisanym w Licencji na treści. Java i OpenJDK są znakami towarowymi lub zastrzeżonymi znakami towarowymi należącymi do firmy Oracle lub jej podmiotów stowarzyszonych.
Ostatnia aktualizacja: 2025-07-27 UTC.
[[["Łatwo zrozumieć","easyToUnderstand","thumb-up"],["Rozwiązało to mój problem","solvedMyProblem","thumb-up"],["Inne","otherUp","thumb-up"]],[["Brak potrzebnych mi informacji","missingTheInformationINeed","thumb-down"],["Zbyt skomplikowane / zbyt wiele czynności do wykonania","tooComplicatedTooManySteps","thumb-down"],["Nieaktualne treści","outOfDate","thumb-down"],["Problem z tłumaczeniem","translationIssue","thumb-down"],["Problem z przykładami/kodem","samplesCodeIssue","thumb-down"],["Inne","otherDown","thumb-down"]],["Ostatnia aktualizacja: 2025-07-27 UTC."],[],[],null,["# Determine flag usage and type\n\nFeature launch flags are used by Google as an approach to ensuring stable\ncode branches. These flags are also required for certain types of contributions\nto AOSP. Before implementing feature launch flagging, determine if\na flag is necessary for your change. And, if a flag is necessary, you should\ndetermine the type of flag to use.\n\nDetermine flag usage\n--------------------\n\nTo determine when to use a feature launch flag, follow these guidelines:\n\n- If you are making a change that could cause the AOSP codebase to be unstable,\n such as adding a new feature or fixing a particularly complex bug, use a feature\n launch flag.\n\n- Conversely, if you are making a code change that isn't apt to cause the\n codebase to be unstable, such as modifying comments, you don't need to use a\n feature launch flag.\n\nDetermine flag type\n-------------------\n\nThere are two types of flags: *aconfig flags* and *build flags*.\n\n### Aconfig flags\n\nAconfig flags are used to separate the execution of unreleased code from\nreleased code during the testing and release process. Aconfig flags can be\nread-write or read-only:\n\n- *Read-write aconfig flags* are boolean variables that you can enable (set to\n `true`) or disable (set to `false`) at runtime. Use a read-write flag to test\n and release changes without affecting the stability of a main branch.\n\n- *Read-only aconfig flags* are boolean constants that you can't change at\n runtime. You can convert read-write aconfig flags to read-only aconfig flags\n for code that is stable and ready to release.\n\n Additionally, depending on the compiler you're using, when a read-only flag\n is used, the code that isn't executed might be excluded\n from the build. Therefore, you can use read-only flags to hide any code that\n isn't ready to be part of a release.\n\n### Build flags\n\nBuild flags are build-time constants (strings) and you can't change them during\nruntime. Use these flags in circumstances where you can't use aconfig flags,\nsuch as:\n\n- You have a precompiled or prebuilt piece of code that you want to include in the build.\n- You want to make changes to build system itself.\n- You want to put flags around dependencies to manage code size.\n\n| **Note:** Build flags have special encodings for boolean values (`false: {empty string}, true: \"true\"`)."]]
