1 13/10/2026 10 min

Su Android la rotazione automatica non è un interruttore unico e universale: in pratica stai scegliendo tra blocco globale dell’orientamento, blocco per singola app oppure controllo via policy su dispositivi gestiti. La parte che crea confusione è che il sistema può obbedire al sensore, ma anche a impostazioni dell’interfaccia, a un’app che forza il fullscreen o a una policy MDM che sovrascrive tutto. Se l’obiettivo è “non ruotare quando scelgo una certa modalità”, conviene separare subito i casi: modalità del sistema, modalità dell’app, modalità kiosk/aziendale.

La regola vera: Android ruota per orientamento, non per “gusto” dell’utente

Il comportamento base dipende da tre livelli: sensore/accelerometro, preferenza dell’utente e richiesta dell’app. Se una app dichiara di voler stare in portrait o landscape, il sistema la segue. Se il launcher o la UI rapida mostrano il lock della rotazione, quello blocca il passaggio automatico. Se invece hai un profilo gestito, il device owner può imporre vincoli più rigidi di quelli visibili all’utente.

Il punto operativo è questo: bloccare la rotazione “in base alla modalità scelta” significa definire quale modalità è la sorgente di verità. Se la modalità è “lettura”, in genere vuoi portrait fisso. Se è “video”, vuoi landscape fisso o rotazione libera. Se è “chiosco”, vuoi un orientamento costante e niente scorciatoie utente che lo cambino.

Metodo rapido: blocco dalla UI di Android

Per l’uso normale, il modo più pulito è agire dalle impostazioni rapide. Su molti device trovi il toggle Rotazione automatica nella tendina notifiche. Quando lo disattivi, il sistema resta nell’orientamento corrente finché non lo cambi manualmente ruotando il telefono o finché l’app non forza un orientamento diverso.

Su alcune versioni Android il pulsante non si chiama più così ma mostra un lucchetto o un’icona simile. Il comportamento pratico è identico: blocca l’orientamento corrente. Se il telefono è in verticale quando premi il lock, rimane in verticale; se è in orizzontale, resta in orizzontale. Questo dettaglio è importante perché spesso il problema non è “non ruotare”, ma “non ruotare nella direzione sbagliata”.

Se vuoi verificare che il blocco funzioni davvero, apri un’app che normalmente ruota, ad esempio un browser o un lettore video, poi gira il device. Se la UI resta fissa e non cambia layout, il blocco è attivo. Se invece l’app cambia comunque, allora sta imponendo il proprio orientamento o stai lavorando su un device con policy particolari.

Bloccare la rotazione per una singola app: il caso più frequente

Molte app Android gestiscono l’orientamento a livello interno. In un’app di lettura puoi voler il portrait fisso; in un’app video puoi voler il landscape fisso; in un gestionale puoi voler bloccare tutto per evitare che l’interfaccia salti da un layout all’altro. Qui la scelta corretta è quasi sempre nel codice dell’app, non nel sistema.

In un progetto Android, il controllo classico sta nel manifest o nella Activity. Per bloccare il portrait:

AndroidManifest.xml

<activity android:name=".MainActivity" android:screenOrientation="portrait" />

Per bloccare il landscape:

<activity android:name=".PlayerActivity" android:screenOrientation="landscape" />

Se invece vuoi impedire l’auto-rotazione ma lasciare la scelta manuale all’utente, la strada cambia: non forzi un orientamento fisso, ma gestisci il comportamento dell’interfaccia quando il device ruota. In altre parole, il sistema può ruotare, ma l’app decide se ridisegnarsi o no.

Per controllare il risultato senza andare a intuito, un test minimo è questo: apri l’app, gira il device, osserva se l’Activity viene ricreata o se il layout cambia. Se hai logcat a disposizione, puoi cercare eventi di ricreazione dell’Activity o cambi di configuration.

adb logcat | grep -iE "orientation|configuration|MainActivity"

Se il log non mostra nulla di utile, il gap da chiudere è semplice: aggiungi un log esplicito in `onConfigurationChanged()` o nei lifecycle hook dell’Activity, così vedi subito se la rotazione sta passando dal framework o viene ignorata.

Bloccare la rotazione in base alla modalità dell’app

Qui c’è il caso più interessante: l’utente sceglie una modalità e l’app deve adeguarsi. Per esempio: “lettura”, “video”, “presentazione”. In questo scenario non basta un flag statico. Serve una logica che cambi orientamento in modo deterministico quando cambia la modalità.

Un approccio pulito è trattare la modalità come stato applicativo e mappare ogni stato a un orientamento. Esempio pratico:

  • Modalità lettura: portrait fisso.

  • Modalità video: landscape fisso.

  • Modalità automatica: lasciare il comportamento di sistema.

  • Nel codice Android moderno puoi impostare l’orientamento dell’Activity quando cambia lo stato. Esempio Kotlin:

    when (uiMode) { UiMode.Reading -> requestedOrientation = ActivityInfo.SCREEN_ORIENTATION_PORTRAIT UiMode.Video -> requestedOrientation = ActivityInfo.SCREEN_ORIENTATION_LANDSCAPE UiMode.Auto -> requestedOrientation = ActivityInfo.SCREEN_ORIENTATION_UNSPECIFIED
    }

    La differenza tra `UNSPECIFIED` e un blocco rigido è sostanziale: nel primo caso rimetti il controllo al sistema, nel secondo lo togli all’utente e al sensore. Se la tua modalità è temporanea, usa un ripristino esplicito quando esci da quella schermata. È il punto che molti dimenticano e che poi genera bug del tipo “l’app resta bloccata in orizzontale anche fuori dal player”.

    Se vuoi capire se la tua logica è corretta, controlla l’effetto lato runtime: cambia modalità, ruota il device, osserva se l’Activity mantiene l’orientamento previsto. Se il comportamento è incoerente, spesso il problema è che la nuova richiesta di orientamento arriva troppo tardi o viene sovrascritta da un’altra schermata.

    Bloccare la rotazione senza rompere il layout

    Molti blocchi di orientamento vengono introdotti per ragioni pratiche: evitare ricalcoli grafici, prevenire crash su layout fragili, mantenere leggibili controlli critici. Ma il blocco è una toppa solo se il layout non regge il cambio di configurazione. La scelta migliore, quando possibile, è far funzionare bene entrambe le rotazioni e bloccare solo dove serve davvero.

    Se il layout si rompe in landscape, non partire subito dal lock. Prima verifica se il problema è una schermata non responsive, un fragment non ridisegnato, o un uso improprio di dimensioni fisse. Un test utile è ruotare il device con layout inspector o con un emulatore e vedere se i componenti escono dai vincoli. Se succede, il blocco dell’orientamento è una mitigazione, non la cura.

    In Android è anche possibile gestire i cambi di configurazione manualmente, ma va fatto con criterio. Dichiarare `configChanges` nel manifest evita la ricreazione dell’Activity, ma poi sei tu a dover aggiornare risorse e stato. È un’arma utile, non un default. Per esempio:

    <activity android:name=".MainActivity" android:configChanges="orientation|screenSize" />

    Usalo solo se hai una ragione precisa, perché altrimenti rischi di nascondere il problema invece di risolverlo. Se il tuo obiettivo è semplicemente “non ruotare”, la soluzione più pulita resta spesso `screenOrientation` o la policy di sistema, non il bypass del lifecycle.

    Controllo da ADB: utile per test e diagnosi

    Per verificare il comportamento senza navigare nei menu, ADB è comodo. Non è la soluzione per l’utente finale, ma è ottimo per capire se il problema è nel sistema o nell’app. Il comando sotto mostra lo stato di alcune impostazioni globali legate alla rotazione:

    adb shell settings get system accelerometer_rotation
    adb shell settings get system user_rotation

    In genere `accelerometer_rotation` vale `1` quando la rotazione automatica è attiva e `0` quando è bloccata. `user_rotation` indica l’orientamento scelto. Se i valori non coincidono con quello che vedi a schermo, hai già un indizio: la UI rapida, una policy, oppure l’app stessa sta imponendo un orientamento diverso.

    Per cambiare temporaneamente l’orientamento via shell in un ambiente di test puoi usare comandi di sistema, ma va fatto con attenzione perché stai toccando il comportamento globale del device. Prima verifica il contesto, poi eventualmente prova su un emulatore o su un terminale di test:

    adb shell settings put system accelerometer_rotation 0
    adb shell settings put system user_rotation 0

    Il rollback è semplice: riattiva la rotazione automatica con `accelerometer_rotation 1`. Se lavori su un device condiviso o aziendale, evita cambi persistenti senza sapere chi li gestisce.

    Dispositivi gestiti: quando serve una policy e non una scorciatoia

    Su tablet aziendali, terminali POS, chioschi o device in fleet, il blocco della rotazione va gestito con policy MDM/EMM. Qui il requisito tipico non è solo “non ruotare”, ma anche “non permettere all’utente di cambiare il comportamento”. In quel caso il toggle di Android non basta, perché l’utente potrebbe riabilitare la rotazione o un’app potrebbe uscire dal vincolo.

    La logica corretta è impostare una policy sul profilo o sul device owner che definisca l’orientamento ammesso. Il nome preciso cambia in base al provider MDM, ma la sostanza è sempre la stessa: blocco dell’orientamento, restrizione del pannello rapido, eventuale kiosk mode, e controllo delle app consentite. Se la documentazione del provider non esplicita dove si imposta l’orientamento, il gap va chiuso nel pannello di amministrazione cercando voci come Orientation, Screen rotation, Kiosk o Device restrictions.

    La verifica minima, in ambiente gestito, è osservare due cose: il device rispetta il lock anche dopo reboot e l’utente non può disattivarlo dalla tendina. Se il blocco sparisce al riavvio, la policy non è stata applicata al livello giusto o non è persistente.

    Quando il blocco non basta: sensori, app di terze parti e overlay

    Se hai già bloccato la rotazione ma il comportamento resta anomalo, le cause più comuni sono tre: app di terze parti che forzano overlay o floating window, launcher particolari che gestiscono da soli l’orientamento, oppure impostazioni di accessibilità e produttività che alterano il flusso standard. In quel caso la diagnosi non è “Android non funziona”, ma “qualcuno sopra Android sta intervenendo”.

    Un test semplice è avviare il device in modalità sicura, se disponibile, e verificare se il problema scompare. Se in safe mode la rotazione torna normale, il colpevole è quasi certamente un’app installata. Se invece il comportamento resta invariato, il problema è più in basso: sistema, policy o configurazione dell’app.

    Per un controllo più concreto, osserva anche se il sensore risponde. Su alcuni device l’auto-rotate sembra “rotta” ma in realtà l’accelerometro è disabilitato da una funzione di risparmio energetico o da un’impostazione vendor-specific. In quel caso il comportamento cambia da marca a marca, quindi non conviene fare assunzioni generiche. La verifica da fare è banale: confronta un secondo device dello stesso modello e controlla se il problema è replicabile.

    Scelta pratica: quale soluzione usare nei tre casi più comuni

  • Uso personale: usa il toggle rapido di Android e blocca l’orientamento corrente quando serve. È la soluzione meno invasiva e più facile da annullare.

  • App Android in sviluppo: imposta `screenOrientation` o la logica di stato nell’Activity. È la strada corretta se il requisito è funzionale, non solo operativo.

  • Device aziendale o chiosco: applica una policy MDM/EMM e valida la persistenza dopo reboot. Qui il blocco deve essere amministrabile e auditabile.

  • In pratica, la domanda giusta non è “come blocco la rotazione su Android?”, ma “chi deve avere l’ultima parola sull’orientamento?”. Se la risposta è l’utente, basta la UI. Se è l’app, serve codice. Se è l’azienda, serve policy. Mischiare questi livelli porta quasi sempre a un comportamento incoerente.

    Mini checklist di verifica

  • Il lock rapido è attivo e il device resta nell’orientamento corrente?

  • L’app forza un orientamento nel manifest o via runtime?

  • Ci sono policy MDM, launcher custom o app terze parti che sovrascrivono il comportamento?

  • Se il blocco è temporaneo, il ripristino a `UNSPECIFIED` o alla rotazione automatica è documentato?

  • Se vuoi evitare sorprese, testa sempre il caso limite: ruota il device, cambia schermata, torna indietro, riavvia l’app. È lì che emergono i blocchi impostati male, non nella prova banale fatta una sola volta. Assunzione: il lettore sta lavorando su Android recente; dove il vendor modifica UI o policy, i nomi dei menu possono cambiare ma la logica di controllo resta la stessa.