Call Blocker 3.0: Plataforma de Inteligência e Segurança para Chamadas no Android

Por José Darci Rodrigues Junior

Receber uma chamada de um número desconhecido se tornou uma experiência cada vez mais difícil de interpretar.

É uma empresa tentando entrar em contato? Um cliente? Uma chamada automática? Telemarketing? Um número falsificado? Uma tentativa de golpe?

Aplicativos tradicionais de bloqueio de chamadas normalmente trabalham com listas de números conhecidos, permitindo bloquear ou liberar determinados contatos. Essa abordagem funciona em alguns cenários, mas possui uma limitação importante: ela analisa principalmente o número, e não necessariamente o comportamento associado à chamada.

Foi a partir dessa ideia que desenvolvi o Call Blocker 3.0 — Call Intelligence Platform, um projeto para Android desenvolvido em Kotlin e Jetpack Compose, utilizando o Android Telecom Framework como base para a triagem e análise das chamadas.

O projeto está disponível como código aberto no GitHub:

https://github.com/josedarci/callblocker

O problema não é simplesmente bloquear números

Imagine que seu telefone receba uma chamada de um número desconhecido:

+55 11 98765-4321

Um bloqueador tradicional poderia simplesmente verificar se esse número está em uma lista de bloqueio.

Se não estiver, a chamada provavelmente será permitida.

Agora imagine que, nos últimos minutos, o aparelho tenha recebido chamadas de vários números semelhantes:

+55 11 98765-4321
+55 11 98765-1032
+55 11 98765-7781
+55 11 98765-4420

Individualmente, talvez nenhum desses números esteja em uma lista conhecida de spam.

Porém, analisando o conjunto, surge uma evidência comportamental muito mais interessante.

É justamente nesse ponto que entra o Call Blocker 3.0.

De Call Blocker para Call Intelligence

A proposta do projeto é deixar de pensar apenas em:

"Bloqueie este número."

E passar a trabalhar com uma pergunta mais completa:

"Qual é o nível de risco desta chamada e quais evidências sustentam essa decisão?"

O Call Blocker combina diferentes fontes de evidência para construir uma avaliação de risco.

Entre os principais mecanismos estão:

• análise do contexto da chamada;
• identificação de números desconhecidos;
• reputação local;
• análise comportamental;
• detecção de Neighbor Spoofing;
• detecção de campanhas de discagem;
• histórico de chamadas;
• regras definidas pelo usuário;
• feedback do usuário;
• análise de confiança.

O objetivo é transformar uma decisão simples de bloqueio em uma decisão baseada em múltiplas evidências.

Motor de risco

Um dos componentes centrais da arquitetura é o CallRiskEngine.

O mecanismo trabalha com um score de risco de 0 a 100, permitindo representar diferentes níveis de suspeita.

Um resultado poderia ser representado conceitualmente da seguinte forma:

Risco: 87/100

Evidências:
Número desconhecido
Comportamento em rajada
Similaridade com números recentes
Baixa reputação local
Padrão compatível com campanha

Confiança: Alta

Ação recomendada: Bloquear

Essa abordagem é importante porque o sistema não precisa simplesmente retornar "spam" ou "não spam".

Ele pode trabalhar com níveis de risco e evidências, tornando a decisão mais explicável.

Reputação local

Outro componente importante é o LocalReputationEngine.

A ideia é permitir que um número construa uma reputação dentro do próprio dispositivo.

Se determinado número realiza diversas chamadas e o usuário repetidamente o classifica como spam, essa informação pode influenciar futuras decisões.

Da mesma forma, números considerados confiáveis podem receber uma classificação diferente.

A reputação local utiliza uma escala que pode representar diferentes níveis de confiança:

0 -------------------------------- 100
Muito suspeito                 Confiável

Uma das vantagens dessa abordagem é que o sistema pode utilizar o histórico local sem depender necessariamente de uma consulta a um serviço externo.

Detecção de Neighbor Spoofing

Uma das características mais interessantes do projeto é a tentativa de identificar padrões de Neighbor Spoofing.

Nesse tipo de situação, o número utilizado pelo chamador pode apresentar similaridades com o número do próprio usuário ou com padrões próximos.

Em vez de analisar somente:

Número = X

o sistema pode considerar:

Número
+
Contexto
+
Histórico
+
Similaridade
+
Comportamento
=
Avaliação de risco

Essa abordagem permite identificar padrões que poderiam passar despercebidos por um sistema baseado exclusivamente em listas de bloqueio.

Detecção de campanhas de discagem

Imagine uma central automatizada realizando chamadas utilizando dezenas ou centenas de números diferentes.

Um bloqueador baseado exclusivamente em uma lista de números conhecidos pode ter dificuldade para identificar esse comportamento.

Por isso, o projeto possui um componente dedicado à detecção de campanhas.

O CampaignDetector procura identificar padrões envolvendo múltiplos números e diferentes chamadas.

Assim, o sistema deixa de perguntar apenas:

"Esse número é suspeito?"

E passa a considerar:

"Esses números podem estar fazendo parte do mesmo padrão de comportamento?"

Essa mudança de perspectiva é fundamental para transformar um bloqueador convencional em uma plataforma de inteligência.

Privacidade como princípio arquitetural

Um dos princípios importantes do Call Blocker 3.0 é o processamento local.

A arquitetura foi pensada para realizar suas principais operações no próprio dispositivo, reduzindo a necessidade de enviar informações relacionadas às chamadas para serviços externos.

Entre as informações processadas localmente estão:

• normalização de números;
• análise de contatos;
• cálculo de risco;
• reputação;
• histórico;
• regras do usuário;
• feedback;
• dados utilizados pelos mecanismos de inteligência.

O projeto também possui mecanismos para mascaramento de números em logs.

Por exemplo:

+55 11 *****-4321

Dessa maneira, informações completas podem ser ocultadas em registros de diagnóstico.

Arquitetura do projeto

O projeto foi organizado separando as responsabilidades relacionadas ao domínio, telefonia, inteligência, persistência e serviço de triagem.

Uma visão simplificada da arquitetura é:

com.josedarci.callblocker/

domain/
    model/

core/
    telephony/
        PhoneNumberNormalizer.kt
        ContactResolver.kt
        SpoofingDetector.kt
        NeighborSpoofingDetector.kt
        CallRiskEngine.kt
        PolicyEngine.kt

    intelligence/
        LocalReputationEngine.kt
        BehaviorAnalyzer.kt
        CampaignDetector.kt
        ConfidenceEngine.kt
        SecurityInsightsEngine.kt
        BusinessIdentityProvider.kt
        CollaborativeReputationProvider.kt

data/
    local/
    repository/

service/
    CallBlockerService.kt

Essa separação facilita a manutenção e permite que novos mecanismos de inteligência sejam adicionados sem transformar a camada responsável pela telefonia em um componente excessivamente complexo.

Integração com o Android Telecom Framework

A integração com o Android Telecom Framework é uma das partes fundamentais da aplicação.

O sistema utiliza os mecanismos disponibilizados pelo Android para participar do fluxo de triagem das chamadas.

A partir desse ponto, a chamada pode passar pelo conjunto de regras e mecanismos de inteligência antes da decisão final.

A arquitetura procura manter a integração com o sistema operacional separada dos mecanismos de análise.

Dessa forma:

Android Telecom Framework
            |
            v
CallBlockerService
            |
            v
Análise da chamada
            |
            +----> Contatos
            |
            +----> Reputação
            |
            +----> Comportamento
            |
            +----> Spoofing
            |
            +----> Campanhas
            |
            v
       Motor de risco
            |
            v
     Política de decisão
            |
            v
     Permitir / Bloquear

Essa arquitetura também facilita a evolução dos mecanismos de análise sem modificar completamente a camada de integração com o Android.

Persistência com Room

Para armazenamento local, o projeto utiliza Room.

Entre os componentes relacionados à persistência estão entidades responsáveis por armazenar informações de chamadas, regras, reputação, campanhas e feedback.

Alguns exemplos são:

BlockedCall
UserNumberRule
CallReputationEntity
CampaignEntity
UserFeedbackEntity

O projeto também utiliza migrações explícitas de banco de dados para permitir a evolução do modelo de persistência sem perder informações existentes.

Existe ainda um mecanismo de retenção responsável por controlar por quanto tempo determinadas informações permanecem armazenadas.

Entre as possibilidades estão períodos como:

30 dias
90 dias
1 ano
Permanente

Esse tipo de mecanismo é especialmente importante em aplicações que trabalham com histórico de chamadas e informações potencialmente sensíveis.

Feedback do usuário

Outro conceito importante do projeto é permitir que o usuário participe do processo de classificação.

Depois de uma chamada, o usuário pode indicar como aquela ligação deveria ser classificada.

Por exemplo:

Confiável
Spam
Golpe

Esse feedback pode ser utilizado como uma nova evidência para a reputação daquele número.

Isso cria um ciclo de aprendizado baseado no comportamento do próprio usuário:

Chamada
   |
   v
Análise
   |
   v
Decisão
   |
   v
Feedback do usuário
   |
   v
Atualização da reputação
   |
   v
Próxima análise

Não é necessário utilizar inteligência artificial generativa para construir esse tipo de sistema.

Regras, estatística, histórico, heurísticas e feedback podem produzir mecanismos bastante sofisticados de classificação.

Central de segurança

O projeto também possui uma camada voltada para a geração de informações de segurança.

O SecurityInsightsEngine foi projetado para transformar os dados coletados durante a análise das chamadas em informações mais úteis para o usuário.

Em vez de simplesmente apresentar:

15 chamadas bloqueadas

a aplicação pode evoluir para apresentar informações como:

Chamadas analisadas: 142

Spam identificado: 38
Chamadas suspeitas: 17
Chamadas confiáveis: 71

Campanhas detectadas: 4

Nível de proteção: Alto

O objetivo é transformar dados brutos em informações que permitam ao usuário compreender melhor o comportamento das chamadas recebidas.

Tecnologias utilizadas

O Call Blocker 3.0 foi desenvolvido utilizando principalmente:

• Kotlin
• Android
• Jetpack Compose
• Android Telecom Framework
• Room
• Kotlin Coroutines
• Kotlin Flow
• libphonenumber
• Gradle Kotlin DSL

A interface utiliza Jetpack Compose, enquanto a camada de telefonia utiliza os mecanismos oficiais disponibilizados pelo Android.

Testes automatizados

Um projeto dessa natureza precisa ser especialmente cuidadoso com suas regras de decisão.

Um erro no motor de risco pode fazer com que uma chamada importante seja bloqueada.

O problema inverso também existe: uma chamada potencialmente perigosa pode ser permitida.

Por isso, os mecanismos de inteligência possuem testes unitários destinados a validar diferentes cenários e situações de borda.

A execução dos testes pode ser realizada através de:

./gradlew testDebugUnitTest assembleDebug

A existência de testes é especialmente importante em componentes como o CallRiskEngine, CampaignDetector, NeighborSpoofingDetector e LocalReputationEngine, pois pequenas alterações nas regras podem modificar significativamente o resultado da classificação.

Documentação técnica

Além do código-fonte, o projeto possui documentação específica para diferentes componentes da plataforma.

Entre os documentos estão:

CALL_INTELLIGENCE.md
LOCAL_REPUTATION.md
CAMPAIGN_DETECTION.md
RISK_ENGINE.md
SECURITY.md
PRIVACY.md
TESTING.md

A documentação é uma parte importante do projeto porque permite compreender não apenas como o código funciona, mas também quais são os conceitos e critérios utilizados pelos mecanismos de inteligência.

Possíveis evoluções

O Call Blocker 3.0 foi projetado pensando também em futuras evoluções.

Uma delas é a possibilidade de implementar uma camada de reputação colaborativa.

Nesse modelo, dispositivos poderiam compartilhar informações de reputação sem necessariamente compartilhar diretamente o número original.

Outra possibilidade é utilizar modelos de Machine Learning para identificar padrões comportamentais mais complexos.

Uma arquitetura futura poderia seguir uma lógica semelhante a:

Histórico de chamadas
        |
        v
Características
        |
        v
Análise comportamental
        |
        v
Modelo de classificação
        |
        v
Probabilidade de risco
        |
        v
Motor de decisão

Também existe espaço para ampliar a identificação de empresas e organizações, criando uma camada capaz de diferenciar uma chamada desconhecida de uma chamada legítima proveniente de uma empresa.

Outra possibilidade é ampliar os recursos de analytics locais, permitindo visualizar tendências relacionadas a horários, frequência, campanhas, números recorrentes e evolução do risco.

Mais do que um aplicativo de bloqueio

Um dos principais objetivos do projeto é justamente explorar como diferentes conceitos de engenharia podem ser combinados para resolver um problema cotidiano.

O Call Blocker 3.0 reúne:

Android
Kotlin
Jetpack Compose
Telecom Framework
Persistência local
Análise comportamental
Reputação
Segurança
Privacidade
Testes automatizados
Arquitetura modular

O resultado é uma plataforma que pode ser estudada por diferentes perspectivas.

Para quem trabalha com Android, existe a integração com o sistema de telefonia.

Para quem trabalha com arquitetura, existe a separação entre domínio, dados, serviços e inteligência.

Para quem trabalha com segurança, existem os mecanismos de spoofing, reputação e análise comportamental.

Para quem trabalha com engenharia de software, existe a combinação entre regras, persistência, testes e evolução arquitetural.

Código aberto

O Call Blocker 3.0 está disponível publicamente no GitHub:

https://github.com/josedarci/callblocker

A disponibilização do código aberto também permite que outros desenvolvedores estudem a arquitetura, proponham melhorias, encontrem problemas e contribuam para a evolução do projeto.

Conclusão

O problema das chamadas indesejadas não é simplesmente criar uma lista de números bloqueados.

O verdadeiro desafio é tomar uma decisão confiável diante de informações incompletas.

É exatamente essa ideia que está por trás do Call Blocker 3.0.

Em vez de perguntar apenas:

"Devo bloquear este número?"

o sistema procura responder:

"Quais evidências existem, qual é o comportamento observado, qual é o nível de risco e qual decisão faz mais sentido?"

Essa mudança de perspectiva transforma um simples bloqueador de chamadas em uma plataforma de inteligência para chamadas no Android.

O projeto continua em evolução e representa também um laboratório prático para explorar Android, Kotlin, segurança, análise comportamental, privacidade, arquitetura de software e sistemas de decisão.

Projeto no GitHub:

https://github.com/josedarci/callblocker