Dal prompt alla scheda pubblica
- Cosa ha creato il tuo strumentoWeb app, progetto Expo, Flutter o nativo
- AAB di release firmatoIl file che Google Play accetta
- Account sviluppatore25 $ una tantum, identità verificata
- Moduli dei contenuti dell’appPrivacy, sicurezza dei dati, classificazione
- Test chiuso12 tester, 14 giorni, se il tuo account lo richiede
- Release di produzioneDopo aver ottenuto l’accesso
Il tuo strumento AI cambia solo il primo passaggio. I passaggi dal secondo al sesto sono gli stessi per qualsiasi app Android.
Risposta rapida
Per pubblicare un’app in vibe coding su Google Play come app pubblica, crea un Android App Bundle (AAB) firmato con il framework che il tuo strumento ha effettivamente prodotto, poi completa i requisiti dell’account, dei contenuti dell’app e della release. Per un account sviluppatore personale creato dopo il 13 novembre 2023, l’app richiede anche un test chiuso (closed testing) con almeno 12 tester che hanno attivato il test continuamente per 14 giorni prima che tu possa richiedere l’accesso in produzione. La strada privata di Google AI Studio per le app personali, annunciata il 13 ottobre 2026, è un percorso separato e non crea una scheda pubblica.
La maggior parte degli app builder AI si ferma a un’anteprima funzionante: un URL, una sessione di Expo Go o un APK sul tuo telefono. Nessuna di queste è ciò che Google Play esamina. Questo articolo parte da ciò che il tuo strumento ha effettivamente prodotto, poi ti accompagna attraverso la build, le correzioni, i moduli e il test, nell’ordine in cui li chiede Play Console. Aggiornato al 16 ottobre 2026.
Cosa trovi in questo articolo
Posso pubblicare su Google Play un’app creata con l’AI?
Sì, se l’app finita soddisfa i requisiti di Google Play. Non abbiamo trovato nessuna policy di Google che vieti un’app perché il suo codice è stato scritto dall’AI. Una release pubblica passa le stesse verifiche di revisione, qualità e policy di qualsiasi altra app, quindi usare l’AI per scrivere il codice non ti toglie la responsabilità dell’app finita.
L’annuncio di Google del 13 ottobre 2026 parla proprio del vibe coding di app Android in Google AI Studio. Quello che non crea è una scorciatoia: una scheda pubblica richiede comunque una release funzionante, dichiarazioni accurate e, per molti account personali nuovi, il test chiuso. Non abbiamo trovato nessuna policy di Google datata che prenda di mira le app scritte dall’AI come categoria. Le regole che bloccano le build AI deboli sono quelle generali su utilità e comportamenti non funzionanti.
“Non sono consentite app che offrono solo funzionalità e contenuti limitati.”
Norme del programma per gli sviluppatori di Google Play, Funzionalità minima
Codice AI, funzionalità AI e immagini AI della scheda sono tre domande diverse
L’AI ha scritto il tuo codice
Non esiste una dichiarazione sulla paternità del codice. La revisione guarda l’app che pubblichi: se funziona, cosa fa con i dati e se è utile.
La tua app genera contenuti con l’AI
Le app che generano contenuti in fase di esecuzione rientrano nella policy di Google sui contenuti generati dall’AI: servono misure di protezione contro i contenuti vietati e un modo, all’interno dell’app, per permettere agli utenti di segnalarli.
L’AI ha creato le immagini della scheda
Le immagini e i video della scheda dello Store e promozionali hanno le loro dichiarazioni condizionali con etichetta AI, valutate elemento per elemento. Riguardano gli asset, non il tuo codice.
Per tutto ciò che serve a una nuova app prima della revisione, leggi i requisiti di pubblicazione su Google Play per il 2026.
Vuoi una scheda pubblica o solo un’app sul tuo telefono?
Decidilo per prima cosa, perché l’uso personale privato e una scheda pubblica su Play hanno ora strade d’accesso diverse. Tutto ciò che segue questa sezione riguarda la scheda pubblica.
La strada privata di Google AI Studio a confronto con una scheda pubblica su Play
Un’app che installi solo tu
Il 13 ottobre 2026 Google ha annunciato che le app create in vibe coding in Google AI Studio possono essere installate privatamente sul tuo dispositivo da un catalogo personale. Google descrive il lancio come iniziale in alcuni mercati, Stati Uniti inclusi, per utenti dai 18 anni in su con un account Google standard. La condivisione con una cerchia ristretta è descritta come in arrivo più avanti.
Un’app che chiunque può installare
Una scheda pubblica richiede un account sviluppatore di Play Console (25 $ una tantum, con verifica dell’identità e, per i nuovi account personali, un controllo su un dispositivo Android fisico con Android 10 o versioni successive), un AAB firmato, i moduli dei contenuti dell’app e, per gli account personali creati dopo il 13 novembre 2023, il test chiuso. Google afferma che una release pubblica mantiene la normale revisione di attendibilità, sicurezza e qualità.
Non siamo riusciti a verificare l’elenco completo dei paesi per la strada privata, quindi controlla l’annuncio di Google di ottobre 2026 per il tuo mercato prima di farci affidamento. E non dare per scontato che un’app privata salti i controlli di sicurezza: Google non lo ha detto.
Come ottengo l’AAB dal mio strumento?
Il processo di build Android segue il framework del tuo progetto, non il nome dell’assistente di programmazione. Un pulsante Publish per il web può produrre un sito senza produrre un Android App Bundle, quindi per prima cosa identifica cosa hai: una web app, un progetto Expo o React Native, un progetto Flutter o un builder che esporta direttamente un AAB.
Scegli lo strumento che hai usato
Replit
- Strada per l’AAB
- La documentazione mobile di Replit dice che la pubblicazione su Google Play non è ancora supportata da Replit e che EAS CLI ed EAS Build non sono supportati su Replit. Se il tuo progetto è un’app Expo, esporta il codice sorgente con Git ed esegui la build di produzione Expo (vedi la scheda Expo) sul tuo computer. Se è un progetto web, usa la strada Capacitor descritta nella scheda Lovable.
- Attenzione a
- I consigli che ti dicono di eseguire EAS dalla Shell di Replit sono superati. La strada esportazione più build esterna combina passaggi documentati; Replit non la offre come un unico pulsante.
Lovable
- Strada per l’AAB
- Lovable pubblica siti web. Non ha un sistema integrato di pacchettizzazione o invio agli store. L’opzione documentata è pacchettizzare tu stesso la build web con Capacitor:
npm install @capacitor/android, poinpx cap add androidenpx cap open android, e creare il bundle firmato in Android Studio. - Attenzione a
- La versione principale di Capacitor determina il target API che puoi raggiungere: Capacitor 8 corrisponde all’API 36 e Capacitor 7 all’API 35. Controlla plugin e firma, e ricorda che il wrapper deve comunque essere un’app utile, non solo il sito dentro una cornice.
Bolt
- Strada per l’AAB
- Bolt può creare una web app oppure un progetto mobile Expo. Per un progetto Expo, scaricalo in un editor locale, configura EAS ed esegui la build di produzione Android. Un progetto web ha bisogno di un guscio come Capacitor, oppure di una build nativa separata.
- Attenzione a
- Non eseguire i passaggi di build nativa su un semplice progetto web. La guida di Bolt passa dal test interno alla produzione; aggiungi in mezzo il test chiuso di Google se il tuo account rientra nel requisito.
FlutterFlow
- Strada per l’AAB
- Vai in Settings and Integrations > App Settings > Mobile Deployment > Google Play Store, poi pubblica o scarica l’AAB. FlutterFlow documenta un primo caricamento manuale sul canale di test interno e deployment automatici da lì in poi.
- Attenzione a
- Salva o esporta la chiave di caricamento generata, oppure importa quella originale. Controlla i valori SDK nelle impostazioni Android avanzate; FlutterFlow non promette che ogni progetto rispetti le regole sull’API o sui 16 KB.
Kodular
- Strada per l’AAB
- Usa Export app as AAB (la scorciatoia documentata è Alt + Shift + E) e carica il bundle risultante.
- Attenzione a
- La release 2026.05.3 di Kodular, pubblicata il 27 settembre 2026, ha aggiunto il target API 36, quindi ricrea qualsiasi AAB più vecchio. Il componente deprecato Firebase Database blocca la compilazione finché non lo migri, e ogni estensione richiede una propria verifica di compatibilità.
Expo
- Strada per l’AAB
- Configura EAS e la firma, poi esegui
eas build --platform android --profile production. Scarica l’AAB oppure invialo coneas submit --platform android. - Attenzione a
- Un APK di anteprima non è un caricamento per Play; il profilo production crea un AAB. La documentazione di Expo sull’invio, aggiornata il 9 ottobre 2026, supporta un primo invio automatizzato, che per impostazione predefinita finisce sul canale di test interno. Il test interno non è il test chiuso, quindi scegli il canale consapevolmente.
Cursor o Claude Code (Flutter)
- Strada per l’AAB
- Configura la firma di release, controlla l’application ID e i valori SDK di Gradle, poi esegui
flutter build appbundle. Il bundle si trova inbuild/app/outputs/bundle/release/app.aab. - Attenzione a
- L’assistente non è il runtime; lo è Flutter. Controlla i plugin nativi e mantieni l’application ID originale se stai aggiornando un’app già presente su Play.
Cursor o Claude Code (React Native)
- Strada per l’AAB
- Configura il keystore di caricamento e la firma di release, poi esegui
npx react-native build-android --mode=release. Il bundle si trova inandroid/app/build/outputs/bundle/release/app-release.aab. Se il progetto usa Expo, segui invece la scheda Expo. - Attenzione a
- React Native 0.81 ha reso predefinito il target API 36 e la 0.77 ha aggiunto il supporto ai 16 KB. Sono traguardi, non la prova che ogni libreria della tua app sia conforme.
Ogni strada qui sopra è stata verificata sulla documentazione del fornitore il 16 ottobre 2026; nessuna è stata eseguita su un progetto di prova. I builder cambiano in fretta, quindi verifica la documentazione attuale prima di creare la build. E non alzare a mano il numero del target SDK per far passare un progetto vecchio: passa invece a strumenti che supportano il nuovo target.
Cosa devo correggere prima del caricamento?
Controlla l’artefatto di release prima di invitare chiunque a testarlo. Tre controlli tecnici intercettano la maggior parte delle sorprese da ricostruzione: il livello API target, la dimensione di pagina delle librerie native, e l’identità e la firma dell’app.
Livello API target
Dal 31 agosto 2026 le nuove app e gli aggiornamenti di app per telefoni e tablet devono avere come target Android 16 (livello API 36) o superiore; le app che hanno ottenuto una proroga avevano tempo fino al 1° novembre 2026. Le app per Wear OS, Android Automotive, TV e XR hanno target diversi. I dettagli e la procedura di correzione sono nell’articolo sul livello API target.
Dimensione di pagina di 16 KB e librerie native
Le app che contengono codice nativo devono supportare i dispositivi con pagine di memoria di 16 KB. La guida attuale di Google blocca gli aggiornamenti non compatibili dal 1° febbraio 2027 per le app con target API 35 e superiore, ma questa non è un’esenzione per una nuova app: controlla subito le librerie native. Il supporto ai 16 KB di un framework non dimostra che ogni dipendenza nativa della tua app sia compatibile. Leggi come trovare e correggere l’errore dei 16 KB.
Identità e firma dell’app
“Se modifichi l’ID applicazione, il Google Play Store considera il caricamento come un’app completamente diversa.”
Android Developers, Configurare il modulo dell’app
Quando una ricostruzione con l’AI rigenera il progetto, confronta il nuovo application ID con quello che Play Console conosce già. Conserva la chiave di caricamento e le sue password in un posto sicuro. Con Play App Signing, Google custodisce la chiave di firma dell’app, e la chiave di caricamento con cui firmi ogni bundle è una chiave separata.
Google rifiuterà il mio wrapper web?
Non per il fatto di essere un wrapper. Un wrapper deve rispettare le stesse regole di qualità pubblicate per qualsiasi altra app, e alcune di queste regole colpiscono più duramente i wrapper scarni.
Autorizzazione e funzionalità utile
La policy di Google sullo spam non consente le app che “forniscono una webview di un sito web senza l’autorizzazione del proprietario o dell’amministratore del sito”, né le app il cui scopo principale è inviare traffico di affiliazione a un sito web. La policy sulla funzionalità minima copre a parte le app con contenuti limitati o comportamenti non funzionanti. Un wrapper del tuo sito supera il test dell’autorizzazione, ma deve comunque fare qualcosa di utile e funzionare su un dispositivo reale.
TWA o WebView
Una Trusted Web Activity mostra il tuo sito nel browser dell’utente e dimostra la proprietà tramite Digital Asset Links; una WebView lo mostra all’interno della tua app. Gli sviluppatori segnalano sia app TWA pubblicate sia app rifiutate, e la documentazione pubblica di Google non dice che l’uso di una TWA sia invisibile ai controlli del test. Cambia architettura solo per un problema identificato, non perché un forum dice che i wrapper falliscono sempre.
Se la tua TWA mostra una barra degli indirizzi del browser dopo l’installazione da Google Play, controlla prima i Digital Asset Links rispetto al certificato di firma di Play: la correzione dello SHA-256 in assetlinks.json lo spiega passo per passo.
Diagnostica il rifiuto reale
Leggi la policy citata nell’email di rifiuto e riproduci il problema nella build di release, non nell’anteprima. Un rifiuto per funzionalità non funzionante indica un crash, un login bloccato o una schermata che non si carica, non il framework. Leggi come risolvere un rifiuto per Broken Functionality.
Quali moduli di Play Console mi servono?
Le tue dichiarazioni devono descrivere ciò che fanno davvero l’app pubblicata e le sue dipendenze, inclusi SDK, accesso, analisi, annunci e qualsiasi servizio AI nel cloud. Gli app builder AI spesso li aggiungono senza dirtelo.
“Le app che non accedono a dati utente personali e sensibili devono comunque inviare un’informativa sulla privacy.”
Norme del programma per gli sviluppatori di Google Play, Dati utente
| Modulo | Chi ne ha bisogno | Dove | Completo quando |
|---|---|---|---|
| Informativa sulla privacy | Chi ne ha bisognoOgni app | DoveApp content > Privacy policy, più l’informativa o un link all’interno dell’app | Completo quandoUna pagina pubblica che corrisponde alla tua app e alle sue reali pratiche sui dati |
| Sicurezza dei dati | Chi ne ha bisognoApp sui canali chiuso, aperto o di produzione, anche se non raccolgono dati | DoveApp content > Data safety | Completo quandoRisposte basate sull’inventario reale di SDK, backend e WebView |
| Classificazione dei contenuti | Chi ne ha bisognoOgni nuova app | DoveApp content > Content rating questionnaire | Completo quandoUna classificazione inviata; Google non consente app senza classificazione |
| Accesso all’app | Chi ne ha bisognoApp con login o funzionalità riservate | DoveApp content > App access | Completo quandoUn revisore può raggiungere ogni funzionalità pubblicizzata |
| Annunci e pubblico di destinazione | Chi ne ha bisognoOgni app | DoveApp content > Ads, poi Target audience and content | Completo quandoFasce d’età e comportamento degli annunci reali dichiarati |
| Funzionalità di AI generativa | Chi ne ha bisognoApp che generano contenuti in fase di esecuzione | DoveAll’interno dell’app stessa | Completo quandoMisure di protezione sui contenuti e un modo, nell’app, per segnalare i risultati |
| Accesso ai contatti | Chi ne ha bisognoApp con target API 37+ che richiedono READ_CONTACTS | DoveDichiarazione nei contenuti dell’app | Completo quandoAccesso ampio giustificato, o sostituito dal selettore di contatti, entro il 27 gennaio 2027 |
| Eliminazione dell’account | Chi ne ha bisognoApp che permettono agli utenti di creare un account | DoveUn percorso per richiedere l’eliminazione all’interno dell’app e sul web, con quell’URL web inserito in Play Console | Completo quandoL’eliminazione dell’account rimuove i suoi dati, con l’eventuale conservazione legittima dichiarata |
Le etichette dei menu cambiano tra una pagina di assistenza di Google e l’altra, quindi se un’etichetta è diversa nella tua Console, cerca in App content (Contenuti dell’app). Questi percorsi provengono dalla documentazione di Google, non da screenshot del tuo account.
Dove si colloca il test chiuso?
Dopo la build, i moduli e una release utilizzabile, e prima di richiedere l’accesso in produzione. Google lo richiede per gli account sviluppatore personali creati dopo il 13 novembre 2023; gli account dell’organizzazione e gli account personali più vecchi non rientrano in questa regola.
“Se hai un account sviluppatore personale creato di recente, devi eseguire un test chiuso per la tua app con un minimo di 12 tester che sono stati attivati per almeno gli ultimi 14 giorni senza interruzioni.”
Guida di Play Console, risposta 14151465
Usa il canale giusto
Il test si svolge su un canale di test chiuso. Il test interno è una preparazione utile, con fino a 100 tester per app, ma non conta; configurare il test interno spiega la differenza. Non contano nemmeno un URL di anteprima, una sessione di Expo Go o un APK installato manualmente: i tester attivano il test e installano l’app da Google Play.
Richiedi l’accesso, poi pubblica
Quando la Dashboard indica che sei idoneo, richiedi l’accesso in produzione e rispondi con sincerità alle domande sul tuo test. Google afferma che in genere la revisione richiede al massimo 7 giorni, ma a volte può essere necessario più tempo. L’approvazione ti dà accesso alla produzione; devi comunque preparare e inviare una release di produzione prima che l’app sia pubblica. Se hai appena pagato la quota, cosa fare dopo aver pagato i 25 $ descrive l’intera sequenza.
E se la ricostruzione ha perso la mia chiave o cambiato il pacchetto?
Per prima cosa capisci se la ricostruzione ha cambiato le tue credenziali, l’identità della tua app o entrambe. Perdere una chiave di caricamento è diverso dal perdere una chiave di firma dell’app, e un application ID cambiato crea un’app diversa su Play anche se le schermate sembrano identiche.
| Sintomo | Cosa controllare prima | Come recuperare |
|---|---|---|
| Keystore di caricamento perso | Cosa controllare primaL’app è registrata a Play App Signing? | Come recuperareCrea una nuova chiave di caricamento, esportane il certificato pubblico come file PEM, poi richiedi la reimpostazione della chiave di caricamento in Play Console in Manage Play app signing > Upload key certificate. |
| Chiave di firma dell’app autogestita persa | Cosa controllare primaLa firma la gestiva Google o la gestivi tu? | Come recuperareSenza la chiave originale e senza Play App Signing, aggiornare l’app esistente può essere impossibile. Controlla prima di ricostruirla con una nuova identità. |
| La ricostruzione ha un pacchetto diverso | Cosa controllare primaConfronta il nuovo application ID con quello dell’app pubblicata | Come recuperareRipristina l’application ID originale se vuoi un aggiornamento, poi controlla la firma e il version code. |
| La TWA mostra una barra del browser dopo l’installazione da Play | Cosa controllare primaassetlinks.json elenca il certificato di firma di Play? | Come recuperareCorreggi i Digital Asset Links per il nome del pacchetto e la chiave di firma reali. |
| La build di release non funziona mentre l’anteprima sì | Cosa controllare primaCosa cambia tra l’anteprima e il bundle di release? | Come recuperareProva direttamente la build di release e controlla la sua configurazione, le librerie native e le dipendenze. Un’anteprima funzionante nel browser o in Expo non dimostra che il bundle sia pronto. |
“Se perdi la chiave di caricamento o sospetti che sia stata compromessa, non perdi l’accesso alla tua app.”
Guida di Play Console, Usare Play App Signing
keytool -export -rfc -keystore upload-keystore.jks -alias upload -file upload_certificate.pemUsa il percorso e l’alias reali del tuo keystore. Carichi solo il certificato pubblico; non inviare mai la chiave privata a nessuno.
Checklist prima dell’invio
Invia quando la build di release reale, le dichiarazioni, i dettagli di accesso per il revisore e le prove del test sono tutti coerenti. Spunta ogni passaggio man mano che lo superi.
Dieci passaggi prima dell’invio
0 passaggi su 10 superatiTutti e dieci i passaggi superati. La tua release, i tuoi moduli e le prove del tuo test sono coerenti.
Quando serve un servizio di tester?
Quando hai una release di test chiuso utilizzabile e il problema che resta è trovare 12 persone che attivino il test e restino per 14 giorni. Un servizio di tester non può sistemare la tua build, verificare il tuo account o prendere la decisione al posto di Google.
Molti di quelli che creano app con l’AI arrivano a questo punto per ultimo: l’app funziona, ma nessuno intorno a loro ha un telefono Android, oppure un amico si ritira al nono giorno. PrimeTestLab fornisce tester reali su dispositivi Android reali. Condividi il tuo link di attivazione, i tester attivano il test entro 4-6 ore e restano per tutti i 14 giorni, e un tester che si ritira viene sostituito in giornata (il sostituto inizia i propri 14 giorni, quindi un margine sopra i 12 è importante). Non ci dai mai l’accesso a Play Console, e segui il test su una Dashboard in tempo reale con un report scritto alla fine.
Scopri come funziona il servizio da 12 tester, oppure scegli un piano qui sotto.
Piani attuali
Starter
12 tester
$19.99
Enterprise
25 tester
$27.99
Professional
25 tester
$59.99
Più il 5% di commissione di servizio al checkout (minimo $1.50). Visa o Mastercard tramite Stripe. Se Google non concede l’accesso in produzione dopo il test completo, scegli tu: nuovo test gratuito o rimborso completo.
Domande frequenti
Posso pubblicare su Google Play un’app che ho creato con l’AI?
Sì. Un’app creata con l’AI può essere inviata per una release pubblica, e Google afferma che questa strada mantiene la normale revisione di attendibilità, sicurezza e qualità. Identifica il framework che il tuo strumento ha prodotto, crea il relativo Android App Bundle firmato e completa i requisiti dell’account e dell’app che ti riguardano. Usare l’AI non rende, di per sé, l’app finita pronta.
Replit mi ha dato un link. Dov’è il mio AAB?
Un link web pubblicato non è un bundle Android. Verifica se il tuo progetto è un sito web oppure un progetto mobile Expo o React Native. La documentazione attuale di Replit non supporta la pubblicazione su Google Play né l’esecuzione di EAS su Replit. Esportare il codice sorgente mobile e farne la build con Expo altrove è una strada possibile, ma non è un pulsante di pubblicazione di Replit.
Posso mettere il mio sito Lovable in un’app Android?
Lovable documenta la pacchettizzazione esterna, Capacitor incluso, ma non ha un invio integrato a Google Play. Il guscio Android richiede comunque la firma di release, la configurazione corretta e verifiche su un dispositivo reale. L’autorizzazione a usare il sito è solo uno degli aspetti; l’app deve anche offrire funzionalità utili e un’esperienza stabile. La sola pacchettizzazione non la rende accettabile.
Mi servono tester se ho creato l’app con Expo o FlutterFlow?
Controlla il tuo account Play, non il builder. La regola di Google riguarda gli account personali creati dopo il 13 novembre 2023, e nessuno strumento di build è esente. Un caricamento interno riuscito da Expo o FlutterFlow non completa il test chiuso richiesto. Segui la Dashboard dell’app ed esegui il test sul canale di test chiuso se il tuo account lo richiede.
Una TWA va convertita in WebView per essere approvata?
Nessun requisito di Google che abbiamo trovato impone questa conversione. Google documenta le Trusted Web Activity come un’integrazione Android basata sul browser, e gli sviluppatori segnalano sia release TWA riuscite sia rifiuti. Parti dal rifiuto reale, dall’autorizzazione del sito, dalla funzionalità e dal comportamento della build di release. Le affermazioni secondo cui il test di una TWA sarebbe invisibile a Google non trovano conferma nella documentazione pubblica.
La mia app non raccoglie nulla. Mi servono comunque le informazioni sulla privacy?
Sì. Google richiede un’informativa sulla privacy anche alle app che non accedono a dati personali o sensibili, e le app sui canali chiuso, aperto o di produzione devono compilare la sezione Sicurezza dei dati. Controlla prima ogni SDK e servizio remoto: analisi, annunci, accesso o contenuti web controllati dall’app possono cambiare le risposte corrette anche quando le tue schermate non raccolgono nulla.
Ho perso il mio keystore. Devo creare una nuova app?
Per prima cosa capisci quale chiave hai perso. Con Play App Signing, una chiave di caricamento persa può essere sostituita tramite la reimpostazione della chiave di caricamento di Google, usando il certificato pubblico di una nuova chiave. Perdere una chiave di firma dell’app autogestita senza quella protezione è diverso e può impedire gli aggiornamenti. Controlla la configurazione di firma dell’app originale prima di ricostruirla con una nuova identità.
Posso cambiare il nome del pacchetto quando ricostruisco l’app?
Cambiare l’application ID fa sì che Google Play consideri il bundle come un’app diversa. Se vuoi aggiornare la scheda esistente, ripristina l’application ID originale e firma con le credenziali giuste. Un nome dell’app familiare o un’interfaccia identica non conservano l’identità quando l’identificatore del pacchetto sottostante è cambiato.
Ricreare la build con l’ultima versione del framework risolve l’errore dei 16 KB?
Può risolvere le librerie del framework stesso, ma non dimostra che l’intera app sia compatibile. Plugin nativi, SDK o estensioni possono comunque includere binari non compatibili. Controlla il bundle di release finale e testalo in un ambiente a 16 KB. Google considera le dipendenze native parte della tua app, comprese quelle aggiunte per te da un builder di terze parti.
Le mie modifiche su Lovable aggiorneranno automaticamente l’app su Play?
Dipende da come è costruita l’app. Una TWA mostra i tuoi contenuti web live tramite il browser, mentre un progetto Android pacchettizzato ha una propria release nativa e una propria configurazione. Capisci quali file e servizi tocca una modifica prima di decidere se ti serve un nuovo bundle. Non dare per scontato che ogni modifica al web, ai plugin, alle autorizzazioni o alla firma segua lo stesso processo di aggiornamento.
In sintesi
Riepilogo
Lo strumento AI che hai usato non cambia ciò che Google Play richiede: un AAB firmato, le dichiarazioni e, per gli account personali creati dopo il 13 novembre 2023, un test chiuso con 12 tester che hanno attivato il test per 14 giorni consecutivi. Identifica cosa ha creato il tuo strumento, segui la strada di release di quel framework, sistema i controlli su API target, 16 KB e firma, e compila i moduli partendo dalla build reale. Quando trovare i tester è l’ultima cosa che ti separa dall’accesso in produzione, PrimeTestLab te li fornisce da $19.99. Vedi i piani →