Target API-nivå 36 på Google Play: förlängningen till 1 nov 2026 och lösningen för Expo, Flutter, React Native

Kravet på target API-nivå 36 på Google Play innebär att en release byggd för något lägre än Android 16 inte kan publiceras. Från och med oktober 2026 avvisar Play varje ny app och varje uppdatering som riktar sig mot en lägre nivå, ofta med meddelandet Target SDK of artifact is too low. Appar som fick en policyvarning kunde be om mer tid, men förlängningen upphör 1 november 2026. Den här guiden går igenom vad förlängningen fortfarande ger dig, hur du flyttar Expo, Flutter och React Native till API 36 och vad som brukar gå sönder när du gör det.

Vad blockerar kravet på target API-nivå 36 egentligen?

Det blockerar inskick. Sedan 31 augusti 2026 kan du inte ladda upp en ny mobilapp eller en uppdatering om den inte riktar sig mot API 36. Appar som redan är publicerade och riktar sig mot API 35 eller högre förblir fullt tillgängliga, även för nya användare.

Enligt Googles krav på target API-nivå gäller att "nya appar och appuppdateringar måste rikta sig mot Android 16 (API-nivå 36) eller högre för att kunna skickas till Google Play." Kraven skiljer sig mellan enhetstyper, och det enda fullständiga undantaget gäller permanent privata appar avsedda för intern distribution inom en organisation.

En befintlig app under de nivåerna "kommer bara att vara tillgänglig på enheter med en Android-version som är samma som eller lägre än appens target API-nivå." De som redan har installerat den kan fortsätta använda den som tidigare. Den som har en nyare telefon får däremot veta att appen "gjordes för en äldre version av Android."

Kan du fortfarande få förlängningen före 1 november 2026?

Bara om Play har skickat en policyvarning för din app och formuläret för begäran fortfarande visas där. Även då gäller förlängningen som längst till 1 november 2026, så det handlar om några extra dagar för en åtgärd som nästan är klar, inte om en ny plan.

Google uppger att man skickar "en länk till ett formulär för begäran om förlängning via Notifications" till berörda appar, och att formuläret "finns tillgängligt via informationssidan för varningen eller problemet på sidan Policystatus." Google visar inget formulär för appar som redan uppfyller kraven.

1. Öppna Play Console och välj appen.
2. Leta i Inbox eller Notifications efter meddelandet om target API-nivå. Om det finns där, följ länken.
3. Om inte, gå till Policystatus, öppna varningen eller problemet om target API-nivå och leta efter formuläret för förlängning på informationssidan.
4. Fyll i formuläret för varje berörd app. Varje app har sin egen varning.
5. Oavsett om förlängningen beviljas eller inte, planera att ladda upp en API 36-build före 1 november 2026. Efter det datumet kräver uppdateringar API 36.

Hur flyttar du Expo, Flutter och React Native till API 36?

Den renaste vägen är att uppgradera till en ramverksversion som redan riktar sig mot API 36: Expo SDK 54, React Native 0.81 eller Flutter 3.38. Om du inte kan uppgradera ännu kan du höja siffran för hand, men då måste du själv hantera beteendeändringarna i Android 16.

Expo. Enligt changeloggen för SDK 54 riktar sig SDK 54 och React Native 0.81 "nu mot Android 16." Uppgradera med npx expo install expo@^54.0.0 --fix, kör npx expo-doctor@latest, och om du använder Continuous Native Generation: "Radera katalogerna android och ios om du genererade dem för en tidigare SDK-version." På SDK 53 kan du prova att sätta targetSdkVersion: 36 via pluginet expo-build-properties, men React Native 0.79 hanterar fortfarande bakåt via onBackPressed, så läs nästa avsnitt innan du publicerar.

Flutter. Versionsinformationen för Flutter 3.38 anger standardvärdena flutter.compileSdkVersion (API 36) och flutter.targetSdkVersion (API 36) och "uppmanar starkt till att använda API-nivåvariablerna som Flutter SDK tillhandahåller i dina buildfiler." Version 3.38 kräver också minst Java 17. Om targetSdk = 35 är hårdkodat i din appmodul ändras det inte av Flutter-uppgraderingen, så kontrollera filen.

Bare React Native. Sätt compileSdkVersion och targetSdkVersion till 36 i android/build.gradle. På 0.81 och senare är du i stort sett klar. På äldre versioner lägger du också till android:enableOnBackInvokedCallback="false" i <application> i AndroidManifest.xml. Utan det hoppar bakåtknappen och bakåtgesten över din JavaScript-navigering.

Vad går sönder när en app börjar rikta sig mot Android 16?

Bakåtnavigering och layouter för stora skärmar går oftast sönder. Med API 36 som mål slutar Android anropa onBackPressed, låter dig inte välja bort edge-to-edge och ignorerar lås för orientering och storleksändring på skärmar som är minst 600dp breda.

De ändringar som betyder mest för plattformsoberoende appar, från Googles beteendeändringar i Android 16:

• Predictive back: "onBackPressed anropas inte och KeyEvent.KEYCODE_BACK skickas inte längre." Att sätta android:enableOnBackInvokedCallback="false" är ett tillfälligt sätt att välja bort det.
• Edge-to-edge: windowOptOutEdgeToEdgeEnforcement är "utfasad och inaktiverad", så ett sidhuvud eller en knapp längst ned kan hamna under statusfältet eller gestfältet.
• Stora skärmar: på skärmar som är 600dp och bredare ignoreras screenOrientation, resizableActivity och begränsningar av bildförhållande, vilket kan sträcka ut layouter som bara är gjorda för stående läge. Spel är undantagna. PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY är ett tillfälligt undantag som "inte gäller när appen riktar sig mot API-nivå 37."
• Text: elegantTextHeight ignoreras, vilket kan ändra radhöjden för arabiska, thailändska, tamil och flera andra skriftsystem.
• Hälsosensorer: BODY_SENSORS ersätts av detaljerade hälsobehörigheter som READ_HEART_RATE.

Vilka problem stötte andra utvecklare på när de gick över till API 36?

De offentliga rapporterna hittills visar två typer av problem: beteende hos bakåtknappen som ändras utan något felmeddelande, och bibliotek som gör att target-nivån i paketet som Play tar emot skiljer sig från vad projektfilerna säger.

Audius (React Native 0.79). I pull request #14635 berättar Audius-teamet att Google Play avvisade båda uppladdningarna av Android-version 1.5.186 med Target SDK of artifact is too low. De höjde compileSdk och targetSdk från 35 till 36, satte build tools till 36.0.0 och lade till android.suppressUnsupportedCompileSdk=36, eftersom "RN 0.79 låser AGP 8.8". De satte också enableOnBackInvokedCallback="false", eftersom bakåt utan det "skulle kringgå React Navigation." En senare PR tog bort undantaget efter att de gått över till React Native 0.81, som registrerar en OnBackPressedCallback på egen hand.

En Flutter 3.35.2-app. I Flutter issue #174516 satte en utvecklare targetSdk 36 i Gradle och manifestet, men Play Console rapporterade ändå "Your bundle targets SDK 34, but uses a Play Core library that cannot be used with that version." Att ta bort det gamla biblioteket com.google.android.play:core:1.10.3 ledde till R8-felen "Missing classes". Att åtgärda dem ledde till "You can't rollout this release because it doesn't allow any existing users to upgrade to the newly added app bundles." Paketet godkändes till slut efter att utvecklaren lagt till ProGuard keep-regler, satt minSdk explicit och stängt av uppdelning per språk, skärmtäthet och ABI, till priset av en större nedladdning.

Den gemensamma lärdomen: att ändra siffran i Gradle räcker inte. Audius fick åtgärda beteendet vid körning, och Flutter-utvecklaren fick åtgärda ett beroende som ändrade vad Play läste ut ur paketet. Kontrollera den byggda artefakten och testa på en Android 16-enhet, inte bara konfigurationsfilen.

Hur kontrollerar du en API 36-build innan du laddar upp den?

Läs target-nivån direkt från release-paketet, lägg sedan paketet på ett internt eller stängt testspår och prova bakåtnavigering, insets och en surfplattelayout på Android 16. Ett avslag eller en bugg i produktion kostar mycket mer tid än de här kontrollerna.

Genomarbetat exempel: en Expo SDK 53-app som riktar sig mot API 35 och behöver ytterligare en uppdatering.

1. Kör npx expo install expo@^54.0.0 --fix, sedan npx expo-doctor@latest, och åtgärda det som rapporteras.
2. Om projektet använder Continuous Native Generation, radera de gamla mapparna android och ios och bygg igen. Annars tillämpar du de nativa uppgraderingsändringarna för hand.
3. Bygg release-AAB:n, till exempel med eas build -p android --profile production.
4. Bekräfta target-nivån med bundletool dump manifest --bundle app.aab --xpath /manifest/uses-sdk/@android:targetSdkVersion. Den ska skriva ut 36.
5. Ladda upp till internt test. På en Android 16-telefon trycker du bakåt på varje nästlad skärm, kontrollerar att sidhuvuden och knappar längst ned inte döljs under systemfälten och roterar en surfplatta eller en emulator med justerbar storlek.
6. Flytta upp till produktion med versionsinformation som nämner Android 16-åtgärderna.

För att testa snabbare kan du använda testaruppsättningen i vår guide till stängda tester på Google Play och låna formuleringar till uppdateringstexten från våra exempel på versionsinformation. Om du hellre vill lämna över releasen täcker vår tjänst för inskick till App Store Play Console och App Store Connect för $599 för båda butikerna. Avgifter för utvecklarkonton tillkommer.