Como funcionam os bloqueadores de apps?

Um bloqueador de apps funciona colocando-se entre ti e a app que estás a tentar abrir, e usando o acesso que o sistema operativo lhe concede para impedir essa app de arrancar ou para lhe fazer custar alguma coisa antes de arrancar. No iOS, esse acesso vem quase todo através da própria framework Screen Time da Apple — apps de terceiros não podem simplesmente matar em silêncio outros processos, por isso qualquer coisa que se diga bloqueador num iPhone é, na prática, apenas uma interface para os mesmos App Limits e Communication Limits que a Apple já disponibiliza. No Android, o sistema operativo é mais permissivo: uma app pode pedir permissões de Accessibility Service ou de Usage Access e usá-las para detetar quando uma app bloqueada passa para primeiro plano, cobrindo-a de imediato com o seu próprio ecrã. O mecanismo é diferente em cada plataforma, mas o objetivo é idêntico — intercetar a abertura e decidir o que acontece a seguir.

Os dois mecanismos, e porque se comportam de forma diferente

No iOS, um bloqueador de terceiros funciona normalmente pedindo autorização Family Controls / Screen Time, que lhe permite registar uma lista de apps como "restringidas" através da framework ManagedSettings da Apple. Quando tocas numa app restringida, é o próprio iOS — não a app de terceiros — que interceta o arranque e mostra um ecrã de bloqueio do Screen Time, porque o programador de terceiros nunca tem, de facto, acesso aos dados ou processos das tuas outras apps; só pode pedir ao sistema operativo que as assinale. É também por isto que os bloqueadores de iOS são relativamente consistentes uns com os outros na forma como se comportam: são todos interfaces à volta do mesmo sistema subjacente. No Android, um bloqueador usa em geral a API Accessibility Service (concebida para leitores de ecrã) ou a API Usage Stats para vigiar qual a app em primeiro plano, e quando deteta um nome de pacote bloqueado, desenha uma sobreposição por cima dela antes de conseguires interagir com a app por baixo. Isto dá aos bloqueadores de Android mais flexibilidade — sobreposições mais ricas, fluxos de desbloqueio personalizados como um quiz — mas também mais fragilidade, já que as permissões de acessibilidade podem ser revogadas nas Definições pela mesma pessoa que o bloqueador se destina a travar. Esta divisão também explica uma queixa comum, específica sobre bloqueadores de iOS — a de que muitos deles parecem e sentem-se parecidos entre si apesar de serem feitos por empresas diferentes — já que estão todos limitados ao mesmo conjunto restrito de ganchos que a Apple expõe, em vez de cada um construir do zero um mecanismo de bloqueio genuinamente independente.

O que determina, de facto, se um bloqueio aguenta

A força de qualquer bloqueador de apps resume-se a uma pergunta: quem controla o interruptor de desligar? Um bloqueador que vive inteiramente dentro da mesma conta da pessoa que está a bloquear — sem código separado, sem segundo dispositivo, sem outra pessoa a guardar a chave — é, mecanicamente, sempre reversível por essa mesma pessoa, porque o sistema operativo tem de deixar que as definições de uma app sejam alteradas por quem quer que esteja a usar o telemóvel. O Screen Time da Apple é o exemplo mais claro disto: configurado sem um código Screen Time separado, os App Limits podem ser desligados nas Definições em menos de trinta segundos pela mesma pessoa que deviam restringir. Junta um código que outra pessoa guarda — a configuração pai/filho da Family Sharing à volta da qual o Screen Time foi construído — e o mecanismo não muda, mas quem consegue reverter o bloqueio muda, e é essa a diferença inteira entre uma restrição e uma sugestão. É também por isto que "quão forte é este bloqueador" é uma pergunta ligeiramente enganadora; a framework por baixo da maioria dos bloqueadores numa dada plataforma é, em grande parte, a mesma. O que varia é o que está entre o bloqueio e o toque que o levantaria — nada, uma contagem decrescente, um código escrito, ou algo que exige esforço real. Vale a pena deixar claro que isto não é uma falha específica de nenhuma app; é uma propriedade estrutural de qualquer ferramenta construída para correr num dispositivo que a mesma pessoa possui e está a tentar restringir a si própria, o que é verdade para praticamente todos os bloqueadores de apps de consumo no mercado, não só os mais fracos.

Onde o atrito encaixa no mecanismo

Como o mecanismo subjacente de bloquear ou não bloquear está, em grande parte, fixado pelo sistema operativo, a escolha de design que realmente importa na maioria dos bloqueadores é o que acontece no momento do desbloqueio. Um desbloqueio por temporizador (esperar cinco minutos) acrescenta atraso mas nenhum esforço. Um desbloqueio por código escrito (ir buscar um código a outro dispositivo) acrescenta um pequeno obstáculo logístico. Um desbloqueio de esforço cognitivo — responder a uma pergunta real, fazer uma série de flexões verificada pelo sensor de movimento do telemóvel — acrescenta algo mais próximo do desconforto da tarefa que estavas, à partida, a evitar, o que é um tipo de atrito significativamente diferente de simplesmente esperar. Nada disto muda se a permissão subjacente do sistema operativo pode tecnicamente ser revogada; muda é quanto a pessoa a revogá-la tem de querer isso, naquele momento específico, o que os investigadores do comportamento que estudam o uso compulsivo do telemóvel (por vezes chamado "uso problemático do smartphone" na literatura académica, já que não existe um diagnóstico formal do DSM-5 para a dependência do telemóvel) geralmente tratam como a alavanca mais relevante do que a força bruta da restrição, já que a força de vontade oscila mas um custo consistente não. Vale também a pena notar que atrito e restrição técnica dura não são propriamente abordagens concorrentes, mas sim pontos de um mesmo espetro — um Downtime agendado sem código é fraco em ambos os eixos, um limite protegido por código é forte no eixo técnico mas não oferece atrito nenhum se o código for conhecido, e um desbloqueio por quiz é comparativamente fraco no eixo técnico (nada impede desinstalar a app por completo) mas forte a exigir envolvimento ativo e trabalhoso no momento específico que importa.

Onde entra o Mr. Grummel

O Mr. Grummel usa a versão deste mecanismo baseada em esforço: em vez de um temporizador ou de um código escrito, passar um bloqueio significa responder corretamente a uma pergunta real de quiz. Não tenta ser um bloqueio técnico mais forte do que o sistema operativo permite — nenhuma app o consegue, sem uma segunda pessoa a guardar um código — está desenhado para elevar o custo cognitivo do momento em que, de outra forma, tocarias diretamente para passar. Essa escolha de design reflete uma aposta específica: que, para a maioria das pessoas, na maior parte do tempo, o problema não é precisar de um cadeado tecnicamente inquebrável, é uma solução alternativa sem custo estar demasiado fácil de alcançar.