LineageOS: resolver o erro de PIN “Screen lock was already changed”

Depois de instalar o LineageOS no meu Samsung Galaxy S10+, não conseguia definir um PIN para desbloquear o ecrã. Introduzia o novo PIN, confirmava-o e recebia sempre a mesma mensagem:

Screen lock was already changed. Try again with the new screen lock.

Já tinha feito wipe de data e cache e reinstalado o LineageOS duas vezes. O erro continuava. A mensagem sugeria que já existia outro PIN, mas o diagnóstico por ADB mostrou o motivo: a proteção contra reposição de fábrica, ou FRP, estava ativa e impedia a criação de uma credencial de bloqueio.

A solução passou por limpar esse estado no Lineage Recovery. Pelo caminho apareceu um segundo erro, porque o comando procurava a partição num caminho que não existia no recovery. Fica aqui o processo que funcionou.

O dispositivo onde aconteceu

Este foi o ambiente em que confirmei o problema e a solução:

O telemóvel já tinha o bootloader desbloqueado, Lineage Recovery instalado e acesso ADB autorizado por USB. Os passos abaixo partem desse contexto. O caminho da partição pode ser diferente noutros dispositivos.

Confirmar a causa antes de voltar a instalar tudo

Com o Android arrancado, a depuração USB ativa e o computador autorizado, confirmei a ligação:

adb devices

Depois de tentar criar o PIN, consultei os registos. Em macOS ou Linux, este filtro ajuda a encontrar as linhas relevantes:

adb logcat -d -v threadtime | grep -i -E 'SaveAndFinishWorker|LockSettingsService|factory reset protection'

O erro que aparecia por trás da mensagem das Definições era bastante mais claro:

Failed to set lockscreen credential
java.lang.SecurityException: Cannot change credential while factory reset protection is active

Consultei também o estado da FRP e do bloqueio do ecrã:

adb shell dumpsys persistent_data_block
adb shell dumpsys lock_settings

Do primeiro comando, estas eram as linhas relevantes:

mDataBlockFile: /dev/block/persistent
mBlockDeviceSize: 524288
Enforcement enabled: true
FRP state: true
Has FRP credential handle: true

No segundo aparecia:

CredentialType: NONE

Ou seja, não existia um PIN configurado para o utilizador atual, mas o estado FRP estava ativo. Era isso que bloqueava a operação.

Esta distinção é importante: a mensagem “Screen lock was already changed” não identifica, por si só, a causa. Se os registos mostrarem outro erro, ou se a FRP já estiver inativa, este procedimento não é o diagnóstico certo.

Porque os wipes não resolveram

A FRP, abreviatura de Factory Reset Protection, é uma proteção associada à reposição de fábrica. Neste dispositivo, o serviço guardava o seu estado numa partição persistente, separada de data e cache.

Os wipes e as reinstalações que fiz não limparam esse estado. O Android arrancava sem PIN, mas continuava a detetar a FRP ativa quando tentava criar um.

Não cheguei a determinar em que momento esse estado ficou ativo. O que consegui confirmar foi a relação direta entre a FRP ativa e a recusa em guardar o PIN.

A primeira tentativa no recovery

O procedimento publicado por luk1337 indica que se deve arrancar no recovery, ativar o ADB e executar wipe-frp.

Reiniciei para o Lineage Recovery:

adb reboot recovery

No telemóvel, selecionei Advanced → Enable ADB. Esta opção pode ter de ser ativada novamente em cada entrada no recovery.

No computador, executei:

adb shell wipe-frp

Mas recebi outro erro:

blockdev: /dev/block/persistent: No such file or directory
FRP block size <= 0

Neste caso, o comando terminou antes de escrever na partição. Reiniciar o telemóvel não resolveu: a FRP continuava ativa.

O detalhe que faltava: o caminho da partição

O script wipe-frp do LineageOS usa a propriedade ro.frp.pst quando não recebe um caminho como argumento.

No meu S10+, essa propriedade apontava para /dev/block/persistent. O caminho existia como ligação simbólica no Android arrancado, mas não estava disponível no recovery. A partição continuava acessível através de /dev/block/by-name/persistent.

Voltei ao recovery, ativei o ADB e confirmei o caminho e o tamanho:

adb shell getprop ro.frp.pst
adb shell ls -l /dev/block/by-name/persistent
adb shell readlink -f /dev/block/by-name/persistent
adb shell blockdev --getsize64 /dev/block/by-name/persistent

Neste dispositivo, os dois últimos comandos devolveram:

/dev/block/sda18
524288

O tamanho correspondia aos 524288 bytes que o serviço tinha reportado no Android. Confirmei também que o comando estava disponível no recovery:

adb shell command -v wipe-frp

O resultado foi /system/bin/wipe-frp.

Não uses /dev/block/sda18 como referência para outro telemóvel. Esse era o destino da partição no meu S10+. Se o caminho não existir ou não conseguires identificar a partição FRP do teu modelo, para aqui: este comando escreve nessa partição. Faz uma cópia dos dados importantes antes de alterar o dispositivo.

O comando que resolveu

Com o caminho confirmado, executei no recovery:

adb shell wipe-frp /dev/block/by-name/persistent

Desta vez, o comando concluiu as escritas sem erros. Depois executei:

adb shell sync
adb reboot

O argumento explícito permitiu ao script aceder à partição correta sem depender do atalho que faltava. Não foi necessário criar ligações simbólicas, formatar a partição inteira ou reinstalar a ROM.

Verificar o resultado

Depois de o Android terminar o arranque, voltei a consultar o estado:

adb shell dumpsys persistent_data_block

As linhas relevantes passaram a ser:

Enforcement enabled: true
FRP state: false
Has FRP credential handle: false

O mecanismo de proteção continuava habilitado, mas o estado FRP que estava a bloquear a configuração já não estava ativo.

Abri as Definições → Segurança e privacidade → Desbloqueio do dispositivo → Bloqueio do ecrã, configurei o PIN e funcionou. Esta correção não apagou os dados que estavam no telemóvel, nem exigiu outra instalação do LineageOS.

Se aparecer wipe-frp: inaccessible or not found, confirma que estás no Lineage Recovery com ADB ativado. No Android arrancado do meu S10+, o comando não estava disponível. Se também faltar no recovery, consulta a documentação e a versão de recovery recomendada para o teu modelo, em vez de substituir o procedimento por comandos de formatação.

Depois de dois reinstalls, a solução acabou por ser um comando com o caminho certo. O passo que permitiu chegar lá foi ler o erro real no logcat: a mensagem das Definições, sozinha, estava a mandar-me procurar o problema no sítio errado.