Coder Legion - Recent posts tagged android

The invitation is an APK

Fri, 30 Oct 2026 19:55:57 +0000

Originally published on the Dunime blog.

How wedding cards and traffic challans became India's most personal malware, and what an investigation has to capture.

The file arrives from an uncle's number, in the family group, a week before a wedding everyone knows about. It ends in .apk, not .pdf. Nobody checks.

Through 2025 and into 2026, the most effective mobile malware in India has not needed an exploit. It needs a reason to be opened. Wedding invitations, pending RTO challans, PM-Kisan instalments, courier delivery slips and KYC reminders have all been used as the wrapper, and police cyber cells from Himachal Pradesh to Telangana have issued warnings about the same pattern.

Why it works

Three things make this campaign different from the lottery SMS it replaced. It arrives from a contact the victim already trusts, because the previous victim's phone forwards it. It borrows an event the victim is expecting, so the name of the file is plausible. And it carries a deadline: a fine to be paid today, a ceremony next week, a parcel waiting at the depot.

None of this is technically sophisticated. It is social engineering fitted to how Indian families and small businesses actually use WhatsApp: large groups, forwarded media, and phones shared between work and home.

What the file does once installed

Published analysis of the challan variant describes a two-stage dropper: the first app is a thin installer that fetches the real payload, hides its own icon and asks for permissions one plausible prompt at a time. Other variants seen in the same period behave the same way.

Stage	What happens
Lure	A familiar contact shares “Wedding_Invite.apk” or “RTO_Challan.apk”.
Install	The victim allows installs from unknown sources.
Grant	SMS, calls, notifications, accessibility, battery exemption.
Hide	Second stage fetched; icon removed; traffic tunnelled.
Harvest	OTPs, SMS, contacts, identity documents.
Spread	The same file is forwarded to every chat.

The common kill chain behind invitation, challan, courier and KYC APKs seen in 2025–26.

OTP interception by reading SMS and notifications before the owner sees them.
Identity harvesting of Aadhaar, PAN, SIM and contact data from the device.
Accessibility abuse that lets the operator tap buttons inside a banking or UPI app.
Battery-optimisation exemption so the service survives restarts and cleaners.
A private VPN tunnel that hides command-and-control traffic from on-device security tools.
Self-propagation through the victim's own WhatsApp, which is also why many accounts end up banned.

The victim's bank sends the OTP. The victim never sees it. That is the whole attack.

What an investigation should preserve

These cases are usually reported after money has moved, often hours later. By then the victim has uninstalled the app, factory-reset the phone, or both. The evidence that makes the case prosecutable is on the device and in the chat, and it is fragile.

The original message with sender number, group name and timestamp, before it is deleted.
The APK itself hashed on collection, so the sample can be tied to other complaints.
Installed package list and permissions captured before uninstalling anything.
SMS and notification history covering the window in which OTPs were intercepted.
Bank and UPI transaction references requested early, while the money trail is still warm.
The infrastructure domains and servers the sample talks to, which link one victim to a campaign.

Linking samples matters more than it looks. The same signing certificate or command server appearing across complaints turns a dozen small frauds into one organised operation, and changes how an agency and a court treat the case.

The legal grounds

Under the Information Technology Act, 2000, installing the payload and taking data is covered by Section 43 read with Section 66; using the victim's identity or OTP falls under Section 66C; and the impersonation that makes the lure work is cheating by personation using a computer resource under Section 66D. The Bharatiya Nyaya Sanhita, 2023 adds cheating and cheating by personation. Electronic evidence now travels under the Bharatiya Sakshya Adhiniyam, which is why hashing and a documented chain of custody from the first collection are worth the trouble.

Individuals should report on the national cybercrime helpline, 1930, or at cybercrime.gov.in, as early as possible; speed is what makes a freeze on the receiving accounts possible. Organisations have a separate clock: CERT-In directions require specified cyber incidents to be reported within six hours of being noticed, and a compromised employee phone with access to company systems can qualify.

What an organisation should change

Block sideloading on every managed device, with no exceptions for senior staff.
Vet the apps that are allowed including vendor and partner apps, before they reach employees.
Treat a suspect phone as an incident and examine it before anyone wipes it.
Tell staff plainly that no government department sends a challan, subsidy or KYC update as an APK.
Rehearse the first hour who isolates the device, who calls the bank, who files the report.

The campaign will keep changing its wrapper: electricity bills, exam results, festival offers. The underlying behaviour does not change, and that is what detection and investigation should be built around.

Sources

This guide is part of Dunime's fraud-help hub — also in हिन्दी, বাংলা, मराठी, తెలుగు and தமிழ், each with a short video: dunime.com/protect.

Need a suspect APK taken apart? Dunime's Shodhan returns a verdict, indicators and a custody log.

Published by Dunime Technologies — custom software, automation and cybersecurity, Delhi NCR, India.

👨🏾💻🚀 Safe Woman Operational System: levando o Mulher Amparada para dentro do Android!

Wed, 28 Oct 2026 14:52:31 +0000

E se o Mulher Amparada não fosse apenas um aplicativo, mas também fizesse parte de um sistema operacional personalizado?

Essa é a proposta do Safe Woman Operational System, um projeto experimental baseado no Android Open Source Project (AOSP), desenvolvido com o objetivo de integrar o Mulher Amparada diretamente à estrutura do sistema Android.

🔐 Mais do que um aplicativo, uma nova possibilidade de integração!

A ideia é explorar como a tecnologia do Mulher Amparada pode ir além da instalação convencional, tornando-se parte de uma imagem personalizada do sistema operacional.

🛠️ O que está sendo desenvolvido?

📱 Integração com o AOSP: preparação dos arquivos necessários para incorporar o Mulher Amparada à estrutura do Android. ⚙️ Configuração personalizada: definição do produto safe_woman-userdebug, com configurações específicas para o sistema experimental. 🔧 Build com Soong: configuração do aplicativo por meio do arquivo Android.bp. 🔐 Permissões privilegiadas: preparação da estrutura de allowlist para permissões de sistema compatíveis, respeitando o modelo de segurança do Android. 🖥️ Testes com Cuttlefish: planejamento da execução em um dispositivo Android virtual, sem depender inicialmente de um aparelho físico.

🌐 Como essa integração funcionaria?

A proposta é utilizar uma árvore completa do AOSP como base e adicionar os componentes específicos do Safe Woman OS, incluindo a integração planejada com o aplicativo Mulher Amparada.

O resultado esperado é uma imagem personalizada do Android, preparada para execução experimental no Cuttlefish.

⚠️ Transparência técnica: o repositório não contém o AOSP completo. Ele reúne apenas uma pequena parte da estrutura necessária para personalizar o sistema. O projeto ainda é experimental, e a compilação funcional depende da árvore completa do AOSP, das dependências e das configurações necessárias.

💡 Por que isso importa?

Porque inovar também significa explorar novas formas de integrar soluções tecnológicas aos sistemas que utilizamos diariamente. O Safe Woman Operational System representa um passo experimental nessa direção, aproximando o desenvolvimento de sistemas operacionais do propósito do Mulher Amparada: contribuir para a proteção, a segurança e a assistência em situações de emergência.

🚀 O futuro que estamos explorando é um Android personalizado com o Mulher Amparada integrado à própria imagem do sistema.

🔗 Conheça o projeto e acompanhe seu desenvolvimento:

https://github.com/mulher-amparada/mulher-amparada-app/tree/main/Safe Woman Operational System

🖥️ Safe Woman Operational System: um experimento de AOSP feito por um garoto autista de 15 anos

Tue, 20 Oct 2026 19:38:55 +0000

Todo mundo já viu o Mulher Amparada (o app). Mas pouca gente sabe que o mesmo dev que compilou 6.117 commits num Samsung A16 5G decidiu dar um passo além: colocar o app dentro do próprio sistema operacional.

É isso mesmo. Estamos falando de AOSP.

🤔 O que é o Safe Woman OS?

O Safe Woman Operational System é um projeto experimental de sistema operacional baseado no Android Open Source Project (AOSP).

O objetivo? Criar uma versão personalizada do Android que já venha com o Mulher Amparada integrado como app de sistema, em vez de ser apenas um APK que a usuária instala depois.

⚠️ Importante desde já: este repositório NÃO contém o AOSP completo. Ele tem apenas os arquivos de personalização do Safe Woman OS — o suficiente para ser colocado dentro de uma árvore AOSP completa.

📁 Estrutura do projeto

Safe Woman Operational System/
├── device/
│   └── safe_woman/
│       ├── AndroidProducts.mk
│       ├── BoardConfig.mk
│       ├── safe_woman.mk
│       └── privapp-permissions-mulher-amparada.xml
│
└── packages/
    └── apps/
        └── MulherAmparada/
            ├── Android.bp
            └── app/
                └── src/
                    └── main/

Tudo o que importa está em dois diretórios: device/safe_woman (configuração do produto) e packages/apps/MulherAmparada (integração do app).

⚙️ Como cada peça funciona

📦 AndroidProducts.mk

Define o alvo do produto:

safe_woman-userdebug

🧩 BoardConfig.mk

Configura a plataforma base do sistema experimental — atualmente preparada para arquitetura x86_64 e execução em ambiente virtual.

🏗️ safe_woman.mk

Define o produto Safe Woman OS e integra componentes específicos, incluindo o app MulherAmparada.

🔐 privapp-permissions-mulher-amparada.xml

Allowlist de permissões privilegiadas para o pacote com.mulheres.

⚠️ Detalhe técnico que muita gente erra: permissões de runtime (localização, microfone, contatos) não se tornam privilegiadas só porque estão nesse XML. Elas seguem o modelo normal de permissões do Android. O XML só vale para permissões compatíveis com o mecanismo de allowlist do priv-app.

📱 Integração do Mulher Amparada

O app é integrado em:

packages/apps/MulherAmparada

Pacote Android:

com.mulheres

E o Android.bp (arquivo do Soong, o build system do AOSP) declara:

privileged: true

Isso significa que o app pode ser tratado como privilegiado do sistema — mas não que todas as permissões serão concedidas automaticamente. Permissões perigosas continuam seguindo o modelo de runtime do Android.

🐟 Cuttlefish: o plano de teste

O Safe Woman OS foi planejado inicialmente para rodar no Cuttlefish — o dispositivo Android virtual oficial do AOSP.

A ideia é chegar a algo assim:

AOSP completo
      +
Safe Woman OS
      +
Mulher Amparada
      ↓
safe_woman-userdebug
      ↓
imagem do sistema
      ↓
Cuttlefish

Assim dá pra testar a estrutura sem depender de um aparelho físico.

🧱 Relação com o AOSP (importante)

O Safe Woman OS não substitui o AOSP. Ele funciona como uma camada de personalização por cima de uma árvore AOSP completa.

Uma árvore AOSP completa tem centenas de componentes, incluindo:

· Android Framework
· Android Runtime (ART)
· Bionic
· System
· Hardware Abstraction Layers (HALs)
· Kernel
· Cuttlefish
· Bibliotecas
· Ferramentas de build
· Componentes externos
· Aplicações do sistema
· Configurações de dispositivos
· Prebuilts
· Ferramentas de desenvolvimento

O Safe Woman OS contém só uma pequena fração disso — apenas os arquivos específicos necessários para definir a personalização.

💡 Transparência do dev: "A existência desses arquivos, por si só, não significa que o sistema completo já possa ser compilado."

🚦 Estado atual (com honestidade)

O projeto é experimental. E o próprio repositório deixa claro:

· A estrutura foi organizada para ser colocada dentro de uma árvore AOSP completa
· Ainda são necessários todos os componentes do AOSP e as dependências do app
· O sucesso da compilação do APK não comprova o funcionamento integral do sistema

🤖 E tem automação? Tem sim.

O workflow simular-os.yml faz toda a mágica no GitHub Actions:

O que ele faz:

Compila o APK (./gradlew assembleDebug)
Cria um emulador Android 15 (API 35) x86_64 com imagem aosp_atd
Inicia o emulador com -writable-system
Tenta injetar o APK em /system/priv-app/MulherAmparada/
Cria o XML de permissões privilegiadas em /system/etc/permissions/
Reinicia os serviços do Android (stop / start)
Verifica com pm path com.mulheres se o pacote foi registrado no caminho correto
Registra informações do sistema (partições, verity, build type, etc.)
Publica os resultados na branch main e como artefato do GitHub Actions

Arquivos gerados na simulação:

· emulator.log — saída do emulador
· mount.txt — sistemas de arquivos montados

🎯 Objetivo futuro

O plano é:

Usar uma árvore AOSP completa como base
Adicionar o Safe Woman OS como configuração personalizada
Integrar o Mulher Amparada diretamente ao sistema
Rodar no Cuttlefish como ambiente virtual

O resultado esperado: um Android personalizado executável em ambiente virtual, com o app de proteção à mulher já embutido no sistema.

💭 Por que isso importa?

Colocar um app de proteção à mulher dentro do sistema operacional — e não apenas como um APK instalável — tem implicações reais:

· Mais difícil de remover por terceiros (como um agressor que vasculha o celular)
· Permissões de sistema podem ser gerenciadas de forma diferente
· Integração mais profunda com o framework do Android
· Mais controle sobre o que acontece quando o app é iniciado

Claro, tudo isso ainda é experimental e o próprio dev é transparente sobre as limitações. Mas a ambição é o que chama atenção: um adolescente autista, programando num celular, tentando construir um Android customizado que já nasce com proteção embutida para mulheres.

🔗 Link do projeto

https://github.com/mulher-amparada/mulher-amparada-app/tree/main/Safe Woman Operational System

https://github.com/mulher-amparada/mulher-amparada-app/tree/main/Resultados da compilação do Safe Woman OS

🧑💻 Considerações finais

O Safe Woman OS é o tipo de projeto que não deveria existir — não porque é ruim, mas porque deveria haver mais gente tentando fazer isso. É um experimento honesto sobre o que é possível fazer quando você:

· Não tem AOSP completo
· Não tem um PC potente
· Não tem curso formal
· Tem um celular, GitHub Actions e vontade

E o mais bonito: o dev documenta tudo — inclusive o que não funciona. O README, os workflows, as limitações... tudo está lá, aberto, para qualquer pessoa continuar.

"O projeto não pretende reproduzir o AOSP inteiro dentro deste repositório. Ele mantém somente os arquivos próprios do Safe Woman OS e a integração planejada com o aplicativo Mulher Amparada."

Se você é dev Android, entusiasta de AOSP ou só curioso, dá uma olhada. E se quiser contribuir — o projeto é open-source.

Fix Gradle Dependency Verification Failures

Sat, 17 Oct 2026 14:45:06 +0000

A Gradle dependency verification failure occurs immediately after upgrading a plugin, adding a module, bumping a library, or enabling a benchmark configuration.

Quick solution:

Run ./gradlew --write-verification-metadata sha256 to update your allowlist incrementally while preserving the security gate.

./gradlew --write-verification-metadata sha256

Gradle's dependency verification guide covers checksums, signatures, metadata generation, and verification failures. The fastest-looking fix is also the most dangerous one: delete verification-metadata.xml or disable verification until CI turns green. Do not do that by reflex.

Gradle's dependency verification exists to make unexpected artifact changes visible. A failure can mean a normal new dependency is missing from the allowlist, but a checksum mismatch can also mean the bytes are not the bytes you previously trusted. The right workflow starts by classifying the failure.

First identify which failure you actually have

Two errors that look similar have very different risk profiles.

Missing verification metadata

A typical message says the artifact has no checksum in the verification metadata. That often happens after adding a new dependency, updating a version, introducing a new test or benchmark module, resolving a previously unused configuration, or changing a plugin that pulls new transitive artifacts. This is usually an expected maintenance task, but the new hashes still need review.

Incorrect checksum

A more serious failure says Gradle expected one checksum but calculated another. That means the artifact identity changed. Possible explanations include a corrupted local cache, different repositories serving non-identical builds, a republished artifact, repository shadowing, or an actual compromised dependency. Gradle's current documentation explicitly treats incorrect checksums as a condition that requires manual investigation. Do not regenerate until green when the failure is a mismatch.

Read the verification report before changing metadata

Gradle produces a verification report that identifies the artifact and configuration involved. In CI, you can also enable more verbose console output when retrieving the HTML report is inconvenient.

The useful debugging questions are which artifact failed, whether the checksum is missing or different, which configuration resolved it, whether that configuration was introduced by the change you expected, which repository supplied the artifact, whether the version is fixed or changing, and whether you can verify the expected bytes from an authoritative source. This prevents the common mistake of assuming the dependency declared in build.gradle is the one that failed. The failing item may be a plugin artifact, POM, metadata file, test runner, Jacoco agent, or transitive dependency.

Understand why one change can produce dozens of failures

Dependency verification is global to the build. The same verification metadata applies across the root project, subprojects, buildSrc, plugins, and included builds. Adding one module can cause Gradle to resolve configurations that were never part of the previous baseline.

For Android and Kotlin projects, these less-obvious configurations often include benchmark runtime classpaths, test fixtures, lint tooling, code coverage agents, Kotlin compiler plugins, Gradle plugins and their metadata, and included builds. That is why adding a single module can become dozens of failed artifacts. It is not necessarily independent problems. It may be one new dependency graph that has never been recorded.

Generate new metadata incrementally

Gradle supports generating verification metadata directly. For projects using signature verification as well, use the combined flag:

./gradlew --write-verification-metadata sha256,pgp

Generation is incremental. Existing information can be preserved while Gradle adds newly resolved artifacts. That is better than deleting the file and rebuilding trust from scratch. A safer maintenance sequence is to keep the current verification file, reproduce the failing resolution, generate the missing metadata, inspect the Git diff, verify the new entries, rerun the build, and commit code and reviewed verification changes together.

Use dry-run output to inspect broad changes

If an upgrade would add many entries, previewing the generated metadata can make review easier. Gradle documents a dry-run mode that writes a separate verification metadata file instead of replacing the main one:

./gradlew --write-verification-metadata sha256 help --dry-run

Be aware of the limitation: a dry run does not execute tasks, so dependencies resolved only during task execution can be missing from the preview. That matters for Android pipelines where instrumentation, benchmark, code generation, or packaging tasks pull additional artifacts.

Review generated entries carefully

Generated metadata is not automatically verified truth. Gradle marks automatically produced trust information so maintainers can distinguish generated values from values they have reviewed.

The review process should ask whether the group, module, and version are expected, whether it came from the repository you intended, whether the dependency change was present in the lockfile or build diff, whether the artifact is signed, whether the checksum can be compared with an authoritative distribution, and whether the update unexpectedly introduced another repository. For critical build tooling, take the time to verify the source independently before changing an entry's provenance.

Never turn a mismatch into a missing-checksum workflow

Suppose CI reports an expected sha256 that differs from the actual sha256. Running write-verification-metadata immediately can normalize the new bytes into your trusted file and erase the warning you needed to investigate.

Instead, clear only the suspect cached artifact and redownload it, confirm the repository endpoint, compare the artifact with an upstream checksum or signature when available, inspect whether the publisher legitimately republished the same version, and accept an additional checksum only when you understand why the variation exists.

Keep verification changes reviewable in Git

verification-metadata.xml belongs in version control. A good pull request makes the relationship obvious between the dependency version change, the verification metadata change for that dependency graph, and the CI verification run. Avoid bundling unrelated checksum churn with an unrelated feature.

CI needs the same resolution path

A local build can pass while CI still fails because the two environments resolve different tasks. Examples include CI running macrobenchmark tasks, downloading sources, enabling release variants, or resolving artifacts missing from a warm local cache. The fix is not to add random hashes until CI becomes quiet. Reproduce the exact CI task set and generate metadata through that resolution path.

Verification and execution checklist

Preserve the existing metadata file instead of deleting it entirely.
Classify missing metadata versus mismatched checksum before running generators.
Inspect the exact artifact and configuration from the failure report.
Reproduce the failing resolution path locally using the exact build configuration.
Generate missing data incrementally using the Gradle flags and review every new entry in the Git diff.

Conclusion

Dependency verification is supposed to interrupt you. The interruption is useful because dependencies are executable inputs to your build. When one of those inputs changes unexpectedly, a secure pipeline should make you explain why. The goal is not to make verification stop complaining, but to make the new dependency graph understood, reviewed, and reproducible.

Two native apps into one React Native codebase in six months

Sun, 11 Oct 2026 18:35:56 +0000

I owned mobile for Pulse, an offline-first inspection app for auditors, on Android and iOS, from an early prototype to 100+ B2B enterprise clients. For most of that time it was two native apps: Kotlin on Android, Swift on iOS, kept in feature parity. In 2025 I led a full rewrite of both into a single React Native codebase. I architected it and built it alongside the team, and we completed it in six months, before I left in May 2025.

This isn’t a “native versus React Native” post. The native apps worked. The earlier posts onPulse’s sync engine and ona local-only app cover why they were built the way they were. This one is about the rewrite: why we did it, what we kept, and how it reached users.

Why rewrite two apps that worked
Keeping two native apps in feature parity has a simple cost: every feature is built twice, once in Kotlin and once in Swift, and every fix has to land in both. That was the reason for the rewrite, in two parts:

One codebase to maintain instead of two.
Shipping faster , because a feature or a fix reaches Android and iOS at the same time.
Neither reason says the native apps were bad. They say that keeping two of them had a cost, and one codebase removes it.

Replicate the behaviour, don’t redesign it
The native apps’ behaviour had years of field use behind it: records that get a temporary local ID and are remapped to a server ID when they sync, photos uploaded before the form that references them, upload progress the auditor can see, and inspection forms built dynamically. So the React Native app replicated that behaviour rather than redesigning it.

The alternative is harder than it looks. A rewrite that also changes how sync works is two projects at once, and every difference between the old app and the new one is something to explain to an auditor in the field. Replicating proven behaviour keeps the rewrite to one question: does the new app do what the old one did?

I built the core, the team built on top
I set the architecture and built the core myself: sync, offline storage and uploads. The team built the screens and features on top of it.

In an offline-first app, that core is where the risk sits. Everything on screen depends on the core behaving the way the native apps did, and in an offline-first app the core is where data gets lost if something is wrong. Screens are easier to see, test and fix; a sync bug can hide until an auditor’s work goes missing.

Rolling out gradually
The new app didn’t replace the native ones for everyone at once. It rolled out gradually, with the native app still available while users moved over.

For an offline-first app that isn’t caution for its own sake. Auditors work without signal, so at any moment someone may have work on the phone that hasn’t reached the server yet. A gradual rollout means a problem in the new app reaches a few users rather than all of them, and there is still a working app to fall back on while it’s fixed.

What I’d tell another team
If you’re rewriting an offline-first app, roll it out gradually. Keep the old app available and move users over in stages. A big-bang switch bets every auditor’s unsynced work on the new app being right on day one.

VPN Configuration Permission: Check Consent Separately from Connection State

Sun, 11 Oct 2026 08:17:48 +0000

A VPN configuration prompt is a system permission decision. This guide separates that decision from profile import and connection state, including why switching VPN apps on Android can bring the prompt back.

Adapted with permission from the original Lisar article by Mohammad Hesameddin Montazerilisar, published July 10, 2026 and updated September 25, 2026. AI assisted editing, platform framing, and fact-checking; the substantive source guidance is human-authored. No device test was performed for this article.

AI-generated conceptual illustration: system permission and a working VPN connection are separate checks. This is not a product or operating-system screenshot.

A VPN client cannot establish a system-level VPN connection without permission from the operating system. That is why a phone, tablet, or computer may display a prompt asking whether the client can add a VPN configuration.

The wording can sound more serious than the action feels. In ordinary use, the prompt is the operating system asking whether the client may create and manage the connection entry that you are trying to set up. It is not, by itself, confirmation that the profile is correct, that access is active, or that a connection has been established.

What the permission prompt is asking

A VPN connection affects how network traffic leaves the device. Because that happens at the operating-system level, the client needs explicit permission to create a VPN configuration.

Depending on the device, the prompt may refer to adding a VPN configuration, allowing a VPN connection, or permitting the client to manage VPN settings. The exact words and screen design vary between operating systems and client versions.

This is different from a normal website permission. A browser page cannot create the system connection on its own. The compatible VPN client handles the imported or saved profile, while the operating system controls whether that client may create the VPN connection.

Why the operating system shows it

The prompt creates a clear boundary between installing or opening a client and allowing that client to affect network routing on the device. It gives the device owner a chance to confirm that the action was intentional.

You will commonly see it during first-time setup, after installing a client on a new device, or when the operating system needs fresh confirmation after a material software change. You may not see it for every later connection because the permission can remain associated with the approved client and configuration.

The absence of a new prompt does not prove that the profile is current. It only means the operating system did not need to ask for that permission again at that moment.

What to verify before approving

Use a short check rather than treating the prompt as a routine button:

Confirm the client. The application named in the prompt should be the compatible VPN client you intentionally opened.
Confirm the source. The profile should have come from a trusted and expected source. Do not use a profile passed around casually.
Confirm the device. Personal devices and organization-managed devices may follow different rules.
Confirm the action. The prompt should follow a setup action or a connection attempt you intentionally started. A new import is not required every time permission is requested.
Confirm ownership. The profile should be assigned or otherwise authorized for your use.

There is no need to open sensitive parts of a profile file to make this decision. The useful checks are source, assignment, client, device, and the action you intentionally started.

Why Android may ask again after another VPN app

Android allows one active VPN service per user or work profile. Starting a different VPN app can replace the current VPN connection. Allowing that other app can also revoke the previous app’s system approval, so returning to your usual client may bring up the permission request again. See the Android VPN guide and VpnService permission reference.

The request can appear when you tap Connect, even if the profile is already imported. The OpenVPN Connect Android guide describes granting permission at that step. A repeated request alone does not show that your profile is damaged; it is not a reason to re-import the file or reinstall the client.

Confirm the app named in the prompt and the connection you intended to start. On a managed device, follow the administrator’s VPN policy. After granting permission, check the client’s connection status separately.

What happens if you decline

If you decline, the client normally cannot create the requested system VPN configuration. The profile might still appear in the client, or the setup may remain incomplete, depending on the operating system and client.

If you are uncertain, pause or decline and verify the source before continuing. The requested configuration remains unapproved; network availability may depend on the device policy already in force.

When you return to the setup flow after verifying everything, the operating system may show the prompt again. The exact behavior depends on the device and client.

Managed devices and organization policies

A company-managed phone or computer may restrict who can add VPN configurations. It may also require a specific client, profile, or approval process.

Do not try to work around those controls. If the device blocks the action or the prompt differs from the documented setup, check with the person responsible for the device or network access. A valid profile does not override device-management policy.

This is one reason setup can differ between a personal device and an organization-managed device even when both use the same general profile type.

Permission granted does not mean connected

Approving the system prompt completes only one part of setup. Several separate states are easy to confuse:

The client is installed.
The profile is imported or saved.
The operating system has allowed a VPN configuration.
The client has attempted to connect.
The connection is active.

A successful permission step does not prove the last two states. After setup, use the client status and the normal first-connection checks to confirm whether the connection is actually active.

Frequently asked questions

Why did I see the prompt on one device but not another?

Operating systems, client versions, prior permissions, and device-management rules can produce different setup flows.

Can the request appear when I tap Connect?

Yes. On Android, a client may ask for system VPN permission when you start a connection with an already imported profile. Granting permission does not by itself confirm an active connection.

Why does Android ask again after I use another VPN app?

Allowing another VPN app can revoke the previous app’s approval. When you return to the earlier client, Android may ask for permission again. This alone does not mean the saved profile is damaged.

Original author: Mohammad Hesameddin Montazerilisar, technical author for Lisar Connect and Manager of MONTAZERI COMPUTERS & REQUISITES TRADING CO. L.L.C, which develops and operates Lisar Connect.

A Post-Restart VPN Checklist: Network Readiness, Client State, and Android Startup Settings

Sat, 10 Oct 2026 08:14:32 +0000

This checklist explains how to verify a VPN after a device restart, including network readiness and the difference between client launch settings and Android traffic-blocking policy.

Adapted with permission from the original Lisar article by Mohammad Hesameddin Montazerilisar, published July 10, 2026 and updated September 26, 2026. AI assisted editing, platform framing, and fact-checking; the substantive source guidance is human-authored. No connection test was performed for this article.

Restarting a phone, tablet, or computer ends active processes and network sessions. A VPN profile may remain saved in its client, but the connection that existed before the restart should not be assumed to remain active afterward.

The useful distinction is between stored configuration and current connection state. A restart can leave one intact while resetting the other.

What survives a restart and what does not

A saved profile is configuration information stored by the client. An active VPN session is a live network state. Most devices preserve the client and its profiles through a normal restart, but they stop the active session while the operating system shuts down.

After startup, the client may:

remain disconnected until you open it;
reconnect automatically when the operating system and network are ready;
display the saved profile but require a new Connect action;
ask for permission again after a major update or policy change;
report an error because the underlying network is not ready yet.

These behaviors vary. The presence of a profile entry does not prove an active connection, and the absence of an automatic reconnection does not by itself mean the profile is damaged.

Wait for the normal network to become usable

After startup, Wi-Fi and mobile services may take time to reconnect. A guest or public network may require a sign-in page again. A laptop can also reconnect to a different remembered network than the one used before shutdown.

Check network readiness together with any VPN policy already applied:

the expected Wi-Fi or mobile connection is active;
ordinary internet access works where device policy permits it; if non-VPN traffic is blocked, check the client status instead of treating this test as proof of a network failure;
any permitted captive-portal sign-in is complete, or the network administrator has provided an approved way to finish it;
the device is not still applying startup updates or network policy.

Starting several VPN attempts while the underlying network is changing can produce timeouts or duplicate status messages that disappear once the device is fully ready.

Android: startup and traffic blocking are different settings

On a compatible Android client, Always-on VPN can start the VPN service after boot. The client still has to establish its connection. The separate Block connections without VPN option can prevent ordinary internet access until that happens. A failed browsing test in this state does not by itself show that the saved profile is damaged. Availability depends on the client and device configuration; see the Android VPN documentation.

OpenVPN Connect has its own Android launch settings: Connect latest tries the most recently connected profile, Restore connection tries to restore the connection active before shutdown, and None takes no action after reboot. Its Always-on tutorial covers the separate system option. These examples describe OpenVPN Connect; check the documentation for the client you actually use.

Read the current client status and any system notification before deciding what failed. On a managed device, ask the administrator for an approved network test or sign-in path; do not disable a required VPN or security policy.

Confirm time and note what changed

Check that the system's actual date and time are correct. A wrong system clock can interfere with connection validation; a different time-zone display alone does not establish that problem.

Also record whether the restart followed an operating-system or client update, a reinstall, a device-management change, a restore, or a network reset. Those events can change permissions or client behavior, but the timing alone does not prove the cause.

Open the intended client and profile

Confirm that the expected client starts normally and that the intended current profile is visible. If several similarly named profiles exist, compare the approved label, assignment, or delivery date instead of choosing the first one.

A common mistake is to download the file again after every restart. That is usually unnecessary when the current profile is already saved. Repeated import attempts can create duplicate client entries and make it harder to know which one was tested.

Do not inspect, copy, or share sensitive profile contents to identify the file. Use the authorized source, visible name, revision label, user or device assignment, and service status.

Handle permission prompts carefully

A system may ask again for permission to add or use a VPN configuration after a major update, client reinstall, device migration, or policy change. Confirm that:

you intentionally opened the expected client;
the prompt names that client;
the profile came from the approved source;
you are allowed to add the configuration on this device.

On an organization-managed device, do not work around a blocked or altered prompt. Follow the approved device policy and contact the responsible administrator.

Recheck connection status instead of assuming

After the client is ready, distinguish these states:

profile is visible;
profile is selected;
client is Connecting;
client reports Connected;
ordinary internet and expected services work while connected.

A familiar system icon from before the restart is not reliable evidence. Open the client or operating-system VPN status and confirm the current state.

If the client reports Connected, use the normal first-connection verification steps documented for the service.

Avoid duplicate setup attempts

When the first attempt fails after startup, preserve the result before changing anything. Record the visible status, timing, network, client version, and whether the restart followed an update. Then compare one condition, such as waiting for the network to stabilize or trying another authorized network.

Avoid:

repeatedly importing the same file;
deleting profiles without confirming which revision is current;
manually editing .ovpn file contents;
changing router, firewall, or device-security settings;
using another person’s profile;
assuming a reinstall is always required.

Frequently asked questions

Do I need to import the profile after every restart?

Normally not when the current profile remains saved in the client. Reimport only when the documented setup or access owner requires a new file.

Can the VPN reconnect automatically after startup?

It depends on the client and approved settings. For example, OpenVPN Connect on Android documents launch choices for the last-used connection and for restoring a previously active connection. An automatic attempt is not proof that the VPN connected.

Why can internet access be unavailable until the VPN connects?

If Android is configured to block connections without VPN, ordinary traffic can remain unavailable while the client connects. Check the active policy and client status. On a managed device, ask the administrator for an approved test instead of disabling the policy.

Original author: Mohammad Hesameddin Montazerilisar, technical author for Lisar Connect and Manager of MONTAZERI COMPUTERS & REQUISITES TRADING CO. L.L.C, which develops and operates Lisar Connect.

How AI Agents Control Smartphones

Fri, 09 Oct 2026 17:51:27 +0000

Observation and input are separate channels: what device control actually requires

Fifth post from the Aiden team (physical AI agent device, USB-connected, open source firmware). This one is less about a specific implementation detail and more about a category of confusion I keep running into in discussions about agents that operate real devices.

The confusion

"The agent controls the phone" gets treated as one capability. It's at least two, and conflating them causes architectural problems that don't show up until you're debugging a failed task.

An input channel is not an observation channel. A compatible external peripheral can deliver taps and keystrokes while providing zero screen visibility. A capture path can provide images while enabling no input at all. Sending a keystroke does not establish where it landed or whether the application accepted it.

This sounds obvious written down. In practice a lot of designs assume that because the system can see a button and can send a click, it knows the click hit the button. It doesn't. Those are two independent facts and you need evidence for the second one.

What each observation method actually gives you

Method	Provides	Blind spot
Screenshot	Rendered screen at a moment	Whether a control is enabled, selected, actionable
OCR	Recognized text, sometimes position	Text doesn't establish control behavior
UI hierarchy	Elements, labels, bounds, states	Coverage varies hugely by app and access path
App-provided state	Structured integration data	Only what the developer chose to expose

Custom-rendered controls are the recurring problem — they can look perfectly clear visually while exposing essentially nothing structurally. Hybrid designs use structured state where it exists and visual interpretation elsewhere, but then you inherit a new problem: what to do when the two sources disagree.

Grounding is a separate capability from perception

Recognizing a button, selecting the correct button, and activating it are three achievements, not one. "Open the second result" has to resolve against the screen as it exists now, not a frame captured two seconds ago before something reflowed. A coordinate can point precisely at the wrong control.

The verification point I'd most like feedback on

The success criterion for a task should be a postcondition, not an issued command. Save an article into a note: success is "exactly one note exists in the intended destination with the correct content," not "the save button was tapped."

This changes retry behavior in a way that matters. If an app appears to stall mid-save, tapping again is not safe recovery — the first operation may have completed, and you've now created a duplicate. Correct move is to inspect the destination before retrying.

That works when there's a queryable end state. A lot of mobile workflows don't give you one, and that's the case I'm least confident we've handled well. If you've built anything that operates interfaces you don't control, how do you deal with an action that may or may not have landed when there's no reliable way to check?

One thing that isn't an implementation detail

An agent working through real interfaces reads text from webpages, documents, and app content. Some of that text will contain instructions. Screen content is task data, not permission to change the goal. Enforcing allowed actions outside the model adds a boundary but doesn't establish complete protection.

Platform notes, since they come up

Android exposes Accessibility services, MediaProjection (session-consent restrictions for apps targeting 14+), UI Automator, ADB, and Intents. Worth separating two questions that get merged: API capability and distribution policy. Google Play's AccessibilityService policy restricts autonomous planning and execution through that API while distinguishing deterministic automation and qualifying accessibility tools — user consent doesn't settle eligibility.

iOS documents App Intents/Shortcuts, XCTest/XCUIAutomation, and AssistiveTouch. None of them is a general device-control grant.

Full writeup with the evaluation framework and the Android/iPhone comparison table: https://aidenai.io/blog/how-ai-agents-control-smartphones/

Firmware is open source if you want to look at how we've structured the capture/input split: https://github.com/AidenAI-IO/aiden-firmware

Dev-board stage, not validated across every device and app combination, and we're honest about that in the article too.

Safe Public Demo Environments for Android Apps

Thu, 08 Oct 2026 23:37:04 +0000

Offering a public demo of an Android application presents a unique architectural challenge. A demo build is exposed to strangers and needs frequent, destructive data resets, yet it must never be able to target or corrupt the real customer database by accident. Relying on a simple runtime UI flag or environment toggle inside the production codebase creates an unacceptable risk of accidental data leakage. This article examines how to build a robust isolation boundary using separate build variants, dedicated demo backends, and fail-closed identity validation.

Why a Demo Toggle Fails as an Isolation Boundary

Many development teams initially attempt to support public demonstrations by adding a toggle within the primary application and backend. The logic often checks whether a demo mode flag is active before skipping certain write operations or routing requests to mock data. This approach fails because a single code path or misconfigured deployment can easily bypass the flag. If a build script accidentally packages the production credentials or connects the demo backend to the primary database, a public reset operation can wipe out real customer records.

True isolation requires separating the trust boundary at every layer of the architecture. The application package name, the backend service instance, and the database project reference must be distinct. If any component in the chain does not match the expected demo configuration, the service should refuse to start entirely rather than attempting to recover or fallback.

Separate Android Build Variants and App Identity

The first layer of defense begins in the Android client. Using build variants allows developers to maintain different application IDs, source sets, and configuration values within the same repository. By modifying the application ID for the demo variant, the operating system treats the demo build and the production build as entirely separate apps on the test device.

android {
    defaultConfig {
        applicationId "com.example.app"
    }
    buildTypes {
        release {
            minifyEnabled true
        }
    }
    flavorDimensions "mode"
    productFlavors {
        production {
            dimension "mode"
            applicationIdSuffix ""
        }
        demo {
            dimension "mode"
            applicationIdSuffix ".demo"
        }
    }
}

This configuration ensures that installation artifacts are distinct. More importantly, keeping the choice fixed in the build artifact prevents users or automated scripts from accidentally activating a demo mode inside a production binary.

Verify Backend and Database Identity

Client-side separation alone is insufficient if the backend can connect to any database via environment variables. A dedicated demo backend must require explicit configuration flags and perform strict startup validation. During initialization, the backend should compare the database project reference derived from its active connection string against an expected demo project reference.

If the strings do not match, the application must immediately throw an unhandled exception and shut down. This fail-closed mechanism ensures that a server misconfiguration becomes immediately visible during deployment rather than remaining a latent vulnerability.

Seed and Reset Guarded Disposable Data

Public demo environments require a mechanism to restore clean state after users alter or delete records. However, this reset mechanism must be guarded against accidental execution against live systems. Implementation evidence suggests a two-step validation model for data lifecycle management:

Initial seeding should only proceed if every demo table is entirely empty. If existing records are detected, the seed routine halts.
Subsequent resets require a persisted security sentinel string to match the configured sentinel, and the database identity must be re-verified immediately before any deletion takes place.

Furthermore, developers should strip all non-essential integrations from the demo service. Production push notification credentials, third-party payment hooks, and external spreadsheet integrations should be omitted so that a compromised or heavily tested demo environment cannot trigger external side effects.

What Process-Local Locks Do Not Protect

When implementing automated reset endpoints, developers frequently reach for concurrency primitives such as a language-specific mutex to prevent overlapping reset requests. While a process-local mutex successfully serializes concurrent coroutines or threads within a single backend instance, it offers no protection in a horizontally scaled architecture. For a related implementation, see Managing Concurrent Git Commits During Automated.

If the demo backend is deployed behind a load balancer with multiple active instances, each instance maintains its own memory space and its own mutex. Two distinct server processes could execute a database reset simultaneously. Protecting a multi-instance demo environment requires database-level locking, a dedicated single-instance worker queue, or another distributed coordination mechanism. For a related implementation, see Safe Multi Environment Database Orchestration.

Release Checklist for a Public Demo

Before launching a public demo environment, verify the following architectural controls:

The demo application variant uses a distinct application ID suffix.
The backend enforces explicit demo mode flags and fails startup if the database project reference does not match.
Initial data seeding refuses to run unless all target tables are empty.
Destructive reset operations require a valid persisted sentinel check and a pre-execution database identity re-validation.
Session secrets and sentinels meet minimum length requirements.
Non-essential production integrations and credentials are completely removed from the demo service deployment.

Preview Cross-System Data Changes Before Sync

Thu, 08 Oct 2026 12:04:12 +0000

A sync button can hide a destructive decision. When a spreadsheet and a backend database disagree because rows were added, removed, edited, duplicated, or marked for deletion, starting an automatic write without checking the shape of those differences risks corrupting data. Users need to know whether the selected source of truth is safe before any changes are applied.

To solve this, a preflight check must calculate a read-only diff first, require one explicit source of truth, block ambiguous keys, and verify the sync by recalculating the diff afterward. This guide explores how to build a reliable preflight check for cross-system data integration using aggregate difference counts and directional guards.

Why a Sync Button Needs a Preflight

Automatic synchronization assumes that both sides agree on identifiers and state. In practice, networks fail, users edit spreadsheets offline, and backend records are updated concurrently. If an application blindly pushes or pulls without an inspection phase, it can overwrite valid updates or propagate duplicate keys.

A preflight stage separates observation from mutation. By inspecting both sides without writing, the system computes an aggregate preview of the state gap. This gives operators visibility into what will change before they commit to an action.

Stable Keys and Row Signatures

Comparing data across systems requires reliable identification. Row positions in a spreadsheet are notoriously fragile because sorting or inserting a row shifts every subsequent index. Integrations must rely on stable business keys rather than physical row numbers.

In addition to stable keys, systems need canonical signatures to detect when shared rows have changed. A signature can be a cryptographic hash or a concatenated string of critical fields. If the key matches between Google Sheets and the database, but the signature differs, the record has been modified.

{
  "stable_key": "user_10293",
  "sheets_signature": "a1b2c3d4",
  "db_signature": "e5f6g7h8",
  "status": "changed"
}

Classifying Missing, Changed, Duplicate, and Deleted Rows

A comprehensive preview categorizes discrepancies into distinct buckets so users can assess the scope of a sync operation. The underlying service should evaluate several entity groups:

Keys that exist only in the spreadsheet.
Keys that exist only in the database.
Shared keys whose canonical signatures differ.
Duplicate keys appearing on either side.
Pending deletions flagged by business logic.

This implementation evidence relies on aggregate counts rather than a field-by-field diff. The preview informs the user how many records are affected, but it does not attempt to display every mutated attribute in a complex UI.

Choosing a Single Source of Truth

When systems diverge, automatic two-way merging often fails because conflict resolution requires domain context that automated scripts lack. If duplicate keys or changed common rows are present, a two-way mode becomes ambiguous and should be rejected.

Instead, the integration must force an explicit choice. The user or operator selects either the spreadsheet or the application database as the authoritative source of truth for that run. Once an authority is chosen, the sync operation flows in a single direction, eliminating merge conflicts.

Confirming Safely and Detecting Stale Previews

A safe run requires an active preview and refuses concurrent execution. If another sync is already running, or if the preview has not been generated, the system blocks the write request.

Process memory often holds these preview objects for simplicity. However, keeping previews in memory introduces a race condition if the underlying data changes between the time the preview is generated and the time the user clicks confirm. A production integration must expire previews after a short duration or bind them to source fingerprints, rejecting stale plans to prevent unintended overwrites.

Post-Sync Convergence Checks

Applying a sync direction is only half the workflow. To ensure the operation succeeded, the service must immediately recompute the differences after the write completes.

If the new preview shows zero discrepancies, the system reports full convergence. If differences remain due to validation errors or partial failures, the service reports a partial result rather than assuming success.

Conclusion

Cross-system synchronization requires discipline to prevent data loss. By inspecting changes in a read-only preflight, relying on stable keys, blocking ambiguous states, and verifying convergence after execution, applications can bridge external tools like spreadsheets and internal databases safely.

Handling a Cold-Starting Android Backend

Thu, 08 Oct 2026 03:44:20 +0000

When an application backend sleeps between requests or takes time to start, an Android app can mistake a temporary cold start for a permanent outage. The opposite failure is also common: a loading spinner retries forever and gives the user no clear way forward. How should an Android app handle an unavailable or cold-starting backend without showing an infinite startup spinner? For a related implementation, see Viewmodel Partial Success Refresh Failure.

The solution is to treat startup health checks as a finite state machine rather than an endless loop. By performing a single pass across configured endpoint candidates during launch, the application can quickly determine if the service is reachable. If the backend fails to respond, the app moves to an explicit unavailable state instead of locking the user into a permanent loading loop. When the user chooses to try again, an explicit retry action refreshes the remote configuration and checks again on a fixed interval, bounded by a visible deadline.

The Startup State Machine and Endpoint Checks

A robust mobile architecture separates initial startup discovery from active user sessions. During the first launch phase, the ViewModel checks configured base URLs once and selects the first healthy endpoint. If none of the candidates respond within the initial pass, the UI exposes a distinct unavailable state. For a related implementation, see To Robust Viewmodel Unit Tests.

This design prevents wasted network traffic and gives the user immediate clarity. Instead of guessing whether the application is frozen or broken, the user sees that the backend is currently offline. The application can distinguish between ordinary unavailability, maintenance modes, and configuration mismatches by evaluating response codes and payload flags.

Bounded Retry with Cancellation

When a cold-starting backend requires a moment to wake up, a manual retry mechanism gives users control without risking runaway resource consumption. The implementation uses a fixed two-second interval and a 75-second total deadline. These specific values correspond to the backend cold-start profile and are not universal defaults.

To prevent overlapping network calls, every new check cancels the previous coroutine job. This cancellation guarantee ensures that if a user triggers multiple retries or if configuration changes mid-check, obsolete requests do not continue running in the background.

class BackendRetryViewModel : ViewModel() {
    private var retryJob: Job? = null

    fun startBoundedRetry() {
        retryJob?.cancel()
        retryJob = viewModelScope.launch {
            val startTime = System.currentTimeMillis()
            while (System.currentTimeMillis() - startTime < 75_000) {
                if (checkHealth()) {
                    _uiState.value = UiState.Ready
                    return@launch
                }
                delay(2_000)
            }
            _uiState.value = UiState.Unavailable
        }
    }

    private suspend fun checkHealth(): Boolean {
        // Perform lightweight health endpoint check
        return false
    }
}

Testing Failure and Recovery

Verifying timeout and recovery logic requires deterministic test execution. Unit tests must cover the initial healthy endpoint selection, the transition to the unavailable state after all candidates fail, the forced configuration refresh on manual retry, and the successful recovery when a later attempt succeeds. Using virtual time control in coroutine tests allows developers to simulate the 75-second deadline and the two-second intervals instantly without slowing down the test suite.

Adapting Retry Strategies for Production

While a fixed interval and a manual trigger work well for predictable cold starts, production systems often require more sophisticated patterns. Developers should consider exponential backoff, jitter, and provider Retry-After headers when dealing with public APIs or heavily loaded microservices. Evaluating connectivity classification helps determine whether a retry should be attempted at all when the device is offline or on a metered connection.

Conclusion for Resilient Startup Flows

Designing a resilient mobile startup flow means balancing persistence with user experience. By implementing a finite health-check pass, offering a bounded manual retry, and cancelling superseded requests, you protect both the client application and the backend service from unnecessary strain. Grounding your retry intervals in actual service behavior rather than guesswork ensures a predictable experience when services wake up.

Offline-first with no server: why HelperBook is local-only

Tue, 06 Oct 2026 08:24:11 +0000

title: Offline-first with no server: why HelperBook is local-only
published: true
date: 2026-09-24 00:00:00 UTC
tags: offlinefirst,kotlinmultiplatform,privacy,android

canonical_url: https://abhishekgoyal.me/writing/offline-first-without-a-server

A lot of my work has been on offline-first apps that still, eventually, talk to a server. At Pulse, I designed the sync contract with the backend and web teams: payloads, upload semantics, failure behaviour. The app worked without signal, but it was always working towards a moment when it would have signal again and reconcile.

HelperBook, the app I’m building now for Indian households to track staff attendance, advances and salary settlements, doesn’t have that moment. There is no signup and no server. Records live on the device, full stop. I want to explain why that’s a design decision and not a missing feature, and what it costs.

The data is the reason not to have a server

HelperBook stores wage data: how many days someone worked, what they were advanced, what they’re owed at month end. That’s exactly the kind of data a household might hesitate to put into an app if it thought the numbers were going somewhere.

Keeping wage data off any server keeps the app outside data-fiduciary scope under India’s DPDP Act, and it gives households a reason to enter real numbers. Those two things are connected. An app that can’t leak your payroll data because it never has it in the first place is a different trust proposition than one that promises to look after your payroll data on a server somewhere.

No sync engine to design

The technical consequence is that there’s no sync contract to design, no conflict resolution, no retry queue, no “what happens if the upload fails halfway through” states. Records live on-device via SQLDelight, inside a shared Kotlin Multiplatform module. Users own their data through export and restore.

That’s a smaller surface area than Pulse’s sync engine, and it’s smaller on purpose. Every state a sync engine has to handle — offline, online, mid-sync, conflicting edits from two devices — is a state HelperBook doesn’t have. The trade-off is direct: no server means no multi-device. If a household member wants to check the ledger from a second phone, they can’t. And if the phone is lost or wiped without an export first, the data is gone. There’s no account to recover it from. That’s a real cost, and it’s one I chose deliberately rather than one I didn’t notice.

Building the honesty into the data model, not the UI

A local-only app has one more responsibility than a server-backed one: the rules have to be right, because there’s no admin panel on the backend to fix a bad month for someone later. So the product rules that matter most live in the data model rather than as UI copy or a setting someone can miss.

Unmarked days default to present, so a worker is never underpaid because someone forgot to tap. Half-days deduct exactly half, with no rounding surprises at month end. And settlement statements are generated bilingually, in English and Hindi, so the employer and the helper can both read every line without one of them having to trust the other’s translation.

As a simplified illustration, the “unmarked day” rule looks something like this:

// Simplified illustration of the rule, not HelperBook's actual code.
fun attendanceValue(mark: DayMark?): Double = when (mark) {
    DayMark.ABSENT -> 0.0
    DayMark.HALF_DAY -> 0.5
    DayMark.PRESENT, null -> 1.0
}

The interesting part isn’t the code, it’s the default: a missing mark resolves to 1.0, not 0.0. In a local-only app, that decision is the whole safety net. There’s no support ticket, no server-side correction, no second system checking the math. Whatever the function returns is what the worker gets paid.

Release engineering without a backend to hide behind

Going local-only doesn’t remove the need for release discipline, it just moves where it matters. HelperBook ships as a signed AAB with R8 rules written for SQLDelight and kotlinx-serialization, so obfuscation doesn’t break the database layer or the serialised export format. Crashlytics is wired in, but the logs carry no names or amounts. Play’s Data Safety declarations describe what the app actually does. And there’s a staged-rollout plan, so a wider release doesn’t reach everyone at once.

None of that is specific to offline-first apps. But when there’s no backend team and no server logs to lean on for debugging, the discipline around what you ship and how you roll it out is the only safety net you have. It’s currently in closed beta on Google Play with 12–20 households, built with Jetpack Compose, min SDK 24, target API 35.

What I’d tell another builder

If you’re weighing whether a product needs a backend at all, the question I’d ask first isn’t “can we build the sync engine,” it’s “what does the user lose if there’s no sync engine.” For HelperBook, the loss is multi-device access and recovery-without-export, and I judged that a household tracking one home’s payroll would rather have neither of those than have their wage data sitting on a server. For a different product, that trade might go the other way.

The second thing I’d say: local-only doesn’t mean less engineering. It means the engineering moves into the data model and the release pipeline instead of into a sync contract. You still have to get the rules right, you still have to obfuscate and log carefully, you still have to plan the rollout in stages. You just don’t get to blame a server for anything.

More on how HelperBook is built is in the case study.

Native, Kotlin Multiplatform or React Native: how I'd choose

Tue, 06 Oct 2026 08:23:00 +0000

title: Native, Kotlin Multiplatform or React Native: how I'd choose
published: true
date: 2026-09-25 00:00:00 UTC
tags: kotlinmultiplatform,reactnative,android,ios

canonical_url: https://abhishekgoyal.me/writing/native-kmp-or-react-native

“Should we build this in Kotlin Multiplatform or React Native?” is a question teams often ask before anyone has written down what the app has to do. That’s backwards. I’ve shipped all three approaches to production: native Android and iOS apps, a shared Kotlin Multiplatform data layer in HelperBook, and a React Native rewrite of two native apps at Pulse. The framework has never been the first decision. The features are.

Start with the features, not the framework

Before choosing anything, I list what the app actually has to do, and which of those things lean on the platform. Camera capture, video playback, background work, offline data, sensors, OS integrations. Then I weigh each option against that list, along with the team that will maintain it and the time and money available.

Most of the heat in “Kotlin Multiplatform vs React Native” debates comes from people comparing the tools in the abstract. For a specific app, the answer is usually much clearer than the debate suggests.

When I’d stay fully native

Sharing code is not free, so sometimes the right amount to share is none.

The market is on one platform. HelperBook is for Indian households, where Android is the phone most people carry, so it shipped on Android first. Its records still live in a shared Kotlin Multiplatform module with SQLDelight, so an iOS app could reuse that data layer rather than rewrite it, but the app itself is native Android.
The app leans hard on platform APIs. On a video-first hiring platform I built 100% of the Android client, and the core of it was CameraX capture, Media3 playback and on-device speech transcription. That is exactly the kind of work where you want the platform’s own APIs directly, not through a layer.
The two apps look and behave differently. If the Android and iOS versions don’t share much UI or flow, a shared UI codebase saves less than it costs.

When Kotlin Multiplatform fits

Kotlin Multiplatform shares business logic and data while each platform keeps a fully native UI. I reach for it when:

Native apps already exist. You can add a shared module to the apps you have and move code into it gradually, instead of rewriting both.
The team writes Kotlin. Android developers can own the shared code without learning a new stack.
The business logic is complex and must match on both platforms. Rules, calculations and offline data that behave slightly differently on Android and iOS are a bug factory. Writing them once removes a whole class of problems.
Native feel matters. The UI stays Jetpack Compose on Android and SwiftUI or UIKit on iOS.

When React Native fits

React Native gives you one codebase for the UI as well as the logic. I recommend it when the timeline is short and the budget is small, and one team has to ship both platforms quickly. It also makes more sense when the screens are the same on both platforms, and when there’s already a React web team whose skills carry over.

Performance, honestly

People search for “Kotlin Multiplatform vs React Native performance” a lot, so here’s my view. Kotlin Multiplatform keeps the UI fully native, and native UI is smoother. For most business apps (forms, lists, dashboards) React Native is fine, and the difference users feel comes far more from the architecture than from the framework.

I haven’t shipped a Flutter app, so I won’t argue for or against it from experience. It’s a real option; it’s just not one I can speak to first-hand.

What Pulse taught me

At Pulse I owned mobile, Android and iOS, from an early prototype to 100+ B2B enterprise clients. For years it ran as two native apps, Kotlin on Android and Swift on iOS, kept at feature parity. Keeping two native apps at parity meant building every feature twice.

In 2025 I led the rewrite of both apps into one React Native codebase, architected and co-built with the team in six months, and it replaced both native apps in production. React Native fitted the situation: one codebase suited the timeline and budget, the web app was already built in React, and the screens were the same on both platforms.

The hardest part of the port was reliable background uploads, which the offline engine depended on. The inspections could run to 500+ questions and 1,000+ photos, captured offline and uploaded in the background once a connection came back, so the upload behaviour had to be as dependable after the rewrite as before it.

Looking back, React Native was a reasonable call for that timeline, budget and team. Knowing what I know now, I’d weigh Kotlin Multiplatform harder for an app with that much offline logic. The sync rules and the upload queue are exactly the kind of code you want written once and shared, while each platform keeps its own native background APIs.

How I’d decide for your app

If your app…	I’d lean towards
Targets one platform first, or leans hard on camera, video, sensors	Native
Already has native apps, or complex logic that must match on both	Kotlin Multiplatform
Needs both platforms fast, on a small budget, with the same screens	React Native

None of these is a rule. They’re where I start, and the feature list decides the rest. If you’re weighing this for a real app, here’s how I help teams adopt Kotlin Multiplatform, and every engagement starts with a paid discovery sprint that ends in a written recommendation you can use with anyone.

Benchmark Android User Journeys with Macrobenchmark

Sun, 04 Oct 2026 12:02:47 +0000

Unit tests can prove that a ViewModel returns the right state, but they cannot measure the latency and frame behavior a user experiences across a sequence of screens and a real application process. To understand real-world responsiveness, you need to use Macrobenchmark with UI Automator to drive a complete interaction from process launch to the user-visible refreshed state, then analyze frame and milestone timings.

Understanding Macrobenchmark Scope

The useful distinction in performance testing is scope. A unit test isolates a method or state transition in memory. A standard UI test checks user-visible behavior and assertions against functional correctness. A Macrobenchmark runs outside the target app process and measures a larger end-user interaction with controlled compilation and performance metrics.

Measuring a complete journey offers visibility into performance issues that isolated tests miss. For example, a multi-screen order-entry flow involves several distinct phases:

Launching the application and waiting for the home screen.
Opening an order-entry surface.
Selecting a package and filling required fields.
Submitting the form.
Waiting for the success message.
Waiting until the new item appears in the pending list.

Measuring these steps together reveals delays that occur after an API response, such as rendering a refreshed list or handling complex layout inflation during navigation. For a related implementation, see Managing Concurrent Git Commits During Automated.

Configuring the Benchmark Target

To run a reliable macrobenchmark, your application must be configured as profileable rather than debuggable. A debuggable build includes performance overhead from the Java Virtual Machine debugger and JIT constraints that distort real-world timing. A profileable build disables debugging while still permitting the benchmarking tool to capture trace information and metric counters.

In your app-level build file, you configure the profileable manifest property inside the release or benchmark build type. The snippet below shows how to configure a dedicated benchmark build variant:

android {
    buildTypes {
        create("benchmark") {
            initWith(buildTypes.getByName("release"))
            signingConfig = signingConfigs.getByName("debug")
            matchingFallbacks += listOf("release")
            applicationIdSuffix = ".benchmark"
        }
    }
}

Alongside the build configuration, the instrumentation test must drive the application using UI Automator selectors. The test runner launches the process, executes the touch and input actions, and measures the resulting frame metrics without altering app bytecode.

Driving the Flow with UI Automator

The benchmark test structure coordinates between the host test process and the target application process. Below is an example of a Macrobenchmark test class that launches an order-entry journey and measures the transition:

@RunWith(AndroidJUnit4::class)
@LargeTest
public class OrderJourneyBenchmark {

    @get:Rule
    val benchmarkRule = MacrobenchmarkRule()

    @Test
    public fun benchmarkOrderSubmission() {
        benchmarkRule.measureRepeated(
            packageName = "com.example.app.benchmark",
            metrics = listOf(FrameTimingMetric(), StartupTimingMetric()),
            compilationMode = CompilationMode.DEFAULT,
            iterations = 5
        ) {
            pressHome()
            startActivityAndWait()

            // Open order entry surface
            device.findObject(By.res("com.example.app", "button_new_order"))
                .click()
            device.wait(Until.hasObject(By.res("com.example.app", "form_container")), 3000)

            // Fill fields and submit
            device.findObject(By.res("com.example.app", "input_package_name"))
                .text = "Standard Package"
            device.findObject(By.res("com.example.app", "button_submit"))
                .click()

            // Wait for success message and refreshed list
            device.wait(Until.hasObject(By.res(
                "com.example.app", 
                "text_success_banner"
            )), 5000)
            device.wait(Until.hasObject(By.res(
                "com.example.app", 
                "list_pending_orders"
            )), 5000)
        }
    }
}

Managing Side Effects and Data Isolation

Running realistic user flows introduces operational side effects that require careful management. A flow that submits forms or creates records will write durable data to your backend or local database. If left unmanaged, repeated benchmark runs accumulate test artifacts that bloat local storage or clutter backend environments.

To maintain valid performance numbers, you should isolate test data using a dedicated staging environment, implement automated database cleanup routines after each iteration, or use disposable test fixtures. Never point an automated performance benchmark against a production database without strict isolation controls. For a related implementation, see Safe Multi Environment Database Orchestration.

Another common pitfall is relying on insufficient sample sizes. A single measured iteration does not yield a reliable distribution or regression baseline. Performance numbers vary due to thermal throttling, background system processes, and CPU frequency scaling. Increasing the iteration count and observing the median value helps filter out transient noise.

Conclusion

Measuring complete user journeys with Macrobenchmark bridges the gap between synthetic unit tests and real-world user experience. By combining profileable builds, UI Automator drivers, and proper data isolation, you can establish repeatable performance baselines that capture multi-screen rendering behavior and latency across your entire application flow.

Why Android Wireless Debugging Keeps Turning Off

Sat, 03 Oct 2026 15:24:23 +0000

You step away from your workstation for ten minutes, and Android silently switches off your wireless debugging toggle. It is a frustrating interruption during active development. When troubleshooting this issue, engineering teams often look at network layers, but the root cause frequently lies in operating system power management. For content creators and technical bloggers, a parallel challenge emerges in organic search analytics. When an existing guide ranks on the first page of Google with high impressions but zero clicks, the instinct is to immediately rewrite the page title. That instinct is dangerous. Mutating an established title to capture new queries often destroys existing search visibility through keyword dilution. This article examines the root cause of Android debugging toggle resets and demonstrates why expanding a content architecture through topic clustering protects rankings while capturing missed search intent.

The Problem with Title Mutation

When reviewing live search analytics for developer troubleshooting guides, a distinct pattern frequently appears. A URL ranks respectably around position seven, accumulating hundreds of impressions every month, yet records zero clicks. Superficial optimization advice suggests changing the page title and meta description to make the snippet more engaging. However, altering metadata on a high-ranking page introduces severe risks:

Keyword Dilution: Search engines rank pages because the exact semantic structure matches a specific intent. Broadening a title to capture secondary phrases confuses the classification algorithm.
Algorithmic Volatility: Modifying anchor text and headings triggers re-evaluation phases, which can drop a stable page deep into the search results.
Intent Mismatch: If searchers are looking for an operating system power policy fix, but the existing page covers network socket configuration, rewriting the title only increases bounce rates and damages user trust.

Extracting exact query logs from search analytics often reveals a divergence in user intent. For wireless debugging, one group of users experiences network timeouts and mDNS discovery failures. Another distinct group experiences the operating system physically turning the developer toggle off upon entering doze mode or screen lock. These are entirely different technical problems requiring separate solutions.

OS Power Management Versus Network Sockets

To solve the user problem correctly, you must separate system setting revocation from protocol-level disconnections. Operating system power management daemons aggressively terminate background background services to preserve battery life. On modern Android builds, specific OEM layers trigger daemon shutdowns based on distinct triggers:

Aggressive OEM background killers in custom ROMs terminate developer settings upon screen lock.
Doze mode idle watchers suspend non-streaming TCP listeners, breaking persistent ADB sockets.
Wi-Fi network roaming or MAC address randomization resets local socket bindings, forcing a manual handshake.

When a developer searches for why wireless debugging turns off, they are usually dealing with the toggle reverting to the off position, not a dropped TCP connection. Addressing this requires actionable workarounds inside the device settings or lightweight workstation scripts.

Implementing Workarounds and Verification

Preventing the wireless debugging toggle from resetting requires configuring both system preferences and development workflows. You can maintain a persistent connection by enabling developer options that prevent sleep states while connected to a power source. For a related implementation, see Choosing Between Chatgpt Claude Developer Workflows.

adb shell settings put global stay_on_while_plugged_in 3

# Verify active TCP connection state and remote debugging port
adb devices -l

Additionally, modern versions of Android allow you to expose hidden developer options directly inside the notification shade. Adding the Quick Settings Developer Tile lets you toggle wireless debugging back on with a single tap, eliminating the need to dig through nested settings menus.

Architectural Resolution Through Topic Clustering

Rather than risking a stable ranking asset by mutating its title, the correct editorial and technical approach is to build a companion asset through a hub-and-spoke model. The original guide remains untouched, preserving its Page 1 authority for network troubleshooting. A new, highly specialized spoke article is published to address operating system power policies and toggle resets.

These two documents cross-link naturally. The network guide points users experiencing toggle shutdowns to the power management spoke. The power management spoke points users whose toggles stay active but lose packets back to the network guide. Search engines recognize this reciprocal linking structure as a definitive topical cluster, establishing deep domain authority without risking existing organic traffic.

Conclusion

Troubleshooting developer tooling requires precise separation between software states, just as technical publishing requires careful handling of search intent. When high impressions yield zero clicks, resist the urge to perform reckless title rewrites that dilute your existing authority. Analyze the query logs, identify the distinct underlying technical problems, and expand your documentation through targeted topic clustering to capture every facet of user intent safely.

Zhidun — Online APK Hardening

Fri, 02 Oct 2026 20:39:22 +0000

Disclosure: This is a promotional introduction to Zhidun.

Choosing online APK hardening and fitting it into your release workflow

If you already have an Android APK ready for release and want to add protection, the useful questions when evaluating an online APK-hardening tool are: what does it protect, how does it fit into the existing release workflow, and is the processed package suitable for users?

1. Identify what you want to protect

Some applications put substantial business logic on the client and need to consider code analysis and reuse. Others are more concerned about their installation package being modified, re-signed, and redistributed. Some need to identify risky runtime environments. These needs involve different protection priorities and affect which configuration options deserve attention.

Start by writing down the main problem you want this hardening step to address, then look at the available settings. This helps avoid judging a tool only by its feature count and makes it easier to check whether the selected protection matches your needs. Zhidun provides online Android APK hardening as one starting point for this evaluation: begin with an existing package, then review and select settings according to your protection goals.

2. Map the workflow from the original APK to the hardened package

A tool’s capabilities matter, but so does how it fits into day-to-day work. What goes in, where do you configure it, and what do you receive afterward? These steps should be clear.

Zhidun uses an online workflow: upload an APK through the website, select a configuration, and download the result after processing. For developers who already have a built APK, this provides a defined entry point: harden the existing package, then bring the downloaded output back into your own validation and release process.

One easy-to-overlook question is whether you can repeat the same steps for the next release. During evaluation, record the original package version, the selected configuration, and the output file. These records help show how the process fits into your existing work. Part of a tool’s value is whether developers understand each step and know what to do with the result.

3. Validate the result against your actual application

A hardening approach suitable for release ultimately needs to be evaluated with the real application. Choose a version you expect to release soon, establish your protection priorities, process it with the corresponding configuration, and then test the application’s key user journeys.

The evaluation can produce concrete findings: which settings were selected, whether the output fits back into the original release process, and what the key-function checks revealed. Compared with broadly labeling a tool “strong” or “weak,” these records are more useful for deciding whether it fits your project.

Online hardening offers an accessible starting point for protecting an existing APK. Zhidun is currently free. If these needs match your application, visit https://zdcod.com to review the available features and configuration options, then begin your evaluation with a version awaiting release.

Perenio Peifc01 IP Camera and Android Application Analysis

Mon, 28 Sep 2026 20:00:58 +0000

Initial Discovery

Using my custom Frida script for cryptographic method detection in Android applications, I captured Java Cipher class doing a decryption operation, along with it's stack trace:

{
  "objectId": "Cipher-30236645",
  "timestamp": 1789412643454,
  "lastSeen": 1789412643488,
  "instanceOverload": "1. [Cipher.getInstance(java.lang.String) -> static Cipher]",
  "transformation": "AES/CBC/PKCS5Padding",
  "algorithm": "AES/CBC/PKCS5Padding",
  "runtimeClass": "javax.crypto.Cipher",
  "providerName": "AndroidOpenSSL",
  "providerVersion": 1,
  "providerInfo": "Android's OpenSSL-backed security provider",
  "providerClass": "com.android.org.conscrypt.OpenSSLProvider",
  "updateInputs": [],
  "updateInputsLen": [],
  "updateOutputs": [],
  "updateOutputsLen": [],
  "initOverload": "6. [Cipher.init(int opmode, Key key, AlgorithmParameterSpec params, SecureRandom random) -> void]",
  "opmode": 2,
  "opmodeString": "DECRYPT",
  "blockSize": 16,
  "keyClass": "javax.crypto.spec.SecretKeySpec",
  "keyAlgorithm": "AES",
  "keyFormat": "RAW",
  "keyBytesHex": "4bf14ea15d7bd3bbfcf9b7d9acc6db5c",
  "keyBytesString": "K.N.]{.........\\",
  "keyBytesFingerprint": "32862b80:16",
  "parameterClass": "javax.crypto.spec.IvParameterSpec",
  "iv": "000000000000000000000000000000",
  "ivFingerprint": "69691905:16",
  "secureRandom": "java.security.SecureRandom",
  "finalOverload": "2. [Cipher.doFinal(byte[] input) -> byte[]]",
  "bytesWritten": 96,
  "input": "7c354a11ebcff3abe4b3c1c359cb16c14a1685851abaca3fd80b2cb8ba1b423f398944c108b2ba6096d43fb0317c5c17 ... [64 more bytes]",
  "output": "{\"commonPrefs\":{\"display_rate_us_after\":0,\"permi ... [48 more bytes]",
  "outputFingerprint": "a29ad7a9:96",
  "stackTrace": [
    "java.lang.Throwable",
    "at javax.crypto.Cipher.doFinal(Native Method)",
    "at se.simbio.encryption.Encryption.decrypt(Encryption.java:179)",
    "at se.simbio.encryption.Encryption.decryptOrNull(Encryption.java:193)",
    "at com.perenio.data.util.EncryptionUtils.decrypt(EncryptionUtils.kt:21)",
    "at com.perenio.data.local.sharedpreference.base.AbsEncryptPreferencesProvider.getStringDecrypt(AbsEncryptPreferencesProvider.kt:15)",
    "at com.perenio.data.local.sharedpreference.base.AbsEncryptPreferencesProvider.getStringDecrypt$default(AbsEncryptPreferencesProvider.kt:13)",
    "at com.perenio.data.local.sharedpreference.SharedPreferencesProvider.<init>(SharedPreferencesProvider.kt:149)",
    "at com.perenio.smarthome.di.module.data.SharedPreferencesModule.provideSharedPreferencesProvider(SharedPreferencesModule.kt:25)",
    "at com.perenio.smarthome.di.module.data.SharedPreferencesModule_ProvideSharedPreferencesProviderFactory.provideSharedPreferencesProvider(SharedPreferencesModule_ProvideSharedPreferencesProviderFactory.java:56)",
    "at com.perenio.smarthome.di.module.data.SharedPreferencesModule_ProvideSharedPreferencesProviderFactory.get(SharedPreferencesModule_ProvideSharedPreferencesProviderFactory.java:44)",
    "at com.perenio.smarthome.di.module.data.SharedPreferencesModule_ProvideSharedPreferencesProviderFactory.get(SharedPreferencesModule_ProvideSharedPreferencesProviderFactory.java:14)",
    "at dagger.internal.DoubleCheck.get(DoubleCheck.java:47)",
    "at com.perenio.smarthome.di.module.data.SectionsModule_ProvideUserSectionFactory.get(SectionsModule_ProvideUserSectionFactory.java:68)",
    "at com.perenio.smarthome.di.module.data.SectionsModule_ProvideUserSectionFactory.get(SectionsModule_ProvideUserSectionFactory.java:19)",
    "at dagger.internal.DoubleCheck.get(DoubleCheck.java:47)",
    "at com.perenio.smarthome.di.component.DaggerAppComponent$AppComponentImpl.synchronizeSubscriptionsUseCase(DaggerAppComponent.java:2416)",
    "at com.perenio.smarthome.di.component.DaggerAppComponent$AppComponentImpl.injectPerenioApp(DaggerAppComponent.java:3815)",
    "at com.perenio.smarthome.di.component.DaggerAppComponent$AppComponentImpl.inject(DaggerAppComponent.java:3036)",
    "at com.perenio.smarthome.PerenioApp.onCreate(PerenioApp.kt:47)",
    "at android.app.Instrumentation.callApplicationOnCreate(Instrumentation.java:1385)",
    "at android.app.ActivityThread.handleBindApplication(ActivityThread.java:7830)",
    "at android.app.ActivityThread.handleBindApplication(Native Method)",
    "at android.app.ActivityThread.-$$Nest$mhandleBindApplication(Unknown Source:0)",
    "at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2546)",
    "at android.os.Handler.dispatchMessage(Handler.java:110)",
    "at android.os.Looper.loopOnce(Looper.java:248)",
    "at android.os.Looper.loop(Looper.java:338)",
    "at android.app.ActivityThread.main(ActivityThread.java:9068)",
    "at java.lang.reflect.Method.invoke(Native Method)",
    "at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:596)",
    "at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:932)\n"
  ]
}

Cryptography Implementation Analysis

Pulling Android Application to Host

Name of the Android application is com.perenio.smarthome.

List relevant packages:

adb shell pm list packages | grep <package-name>

Get full path name for the package with adb shell pm path <package-name>:

package:/data/app/~~s-<base64-string>/<package-name>-n_K_-<base64-string>/base.apk
package:/data/app/~~s-<base64-string>/<package-name>-n_K_-<base64-string>/split_asset_pack.apk
package:/data/app/~~s-<base64-string>/<package-name>-n_K_-<base64-string>/split_config.arm64_v8a.apk
package:/data/app/~~s-<base64-string>/<package-name>-n_K_-<base64-string>/split_config.en.apk
package:/data/app/~~s-<base64-string>/<package-name>-n_K_-<base64-string>/split_config.xxhdpi.apk

Core application logic is stored in base.apk with assets and configs stored in separate .apk files. For the purposes of current research, only the base application file was analyzed.

Pull the base.apk to host machine:

adb pull /data/app/~~s-<base64-string>/<package-name>-n_K_-<base64-string>/base.apk

A shell script that automates package pulling process can be found by following this link.

Application Analysis with JADX and Frida

This section covers analysis of Perenio application's data encryption and decryption methods. Both static analysis with JADX and dynamic analysis using Frida were performed.

One important thing to note: the described encryption method is a local-only encryption method, i.e. it only protects data that is at rest in local storage. Data transmitted via network is protected by TLSv1.3 sessions and SSL certificates pinned into Perenio app.

Searching for se.simbio.encryption.Encryption in Jadx-gui leads to the decompiled code of the Encryption class (whose scope is set to public).

The class has getDefault(String str, String str2, byte[] bArr) { ... } method that creates an object of Builder class, responsible for providing information necessary to construct key and initialization vector (IV) for AES encryption:

This method is called from com.perenio.data.util.EncryptionUtils class and gets hardcoded key and salt values provided as arguments:

The builder method itself builds a key from provided information and has setters and getters for every private variable:

Overloading the getDefaultBuilder method (along with decrypt method) using Frida discloses that the following information is being received during Perenio application's initialization sequence:

During the app initialization stage, Frida overloads for getDefaultBuilder and decrypt methods captured the following information about building a key and IV for AES decryption operation:

{
  "threadId": "2",
  "builder": {
    "algorithm": "AES/CBC/PKCS5Padding",
    "modeBase64": 0,
    "charsetName": "UTF8",
    "digestAlgorithm": "SHA1",
    "iterationCount": 1,
    "iv": "00000000000000000000000000000000",
    "ivParameterSpec": null,
    "key": "A45BE7EF0543D36B4F68DvD3EF4013D4",
    "keyAlgorithm": "AES",
    "keyLength": 128,
    "salt": "BDBA982FAF389694",
    "secretKeyType": "PBKDF2WithHmacSHA1",
    "secureRandom": null,
    "secureRandomAlgorithm": "SHA1PRNG"
  },
  "getDefaultInfo": {
    "key": "A45BE7EF0543D36B4F68DvD3EF4013D4",
    "salt": "BDBA982FAF389694",
    "defaultKey": "00000000000000000000000000000000"
  },
  "encrypted": "fDVKEevP86vks8HDWcsWwUoWhYUauso/2AssuLobQj85iUTBCLK6YJbUP7AxfFwXHjKn3F3URNgh\n/2SvLbPOPqS3wos0B9h8m/Q9jtfCVvEt3TqiLY0dSeff12q/2BmDRKpBQYHFeO+F8UKtMuNdoA==\n    ",
  "hashTheKeyInfo": {
    "keyPlaintext": "A45BE7EF0543D36B4F68DvD3EF4013D4",
    "keyHashed": "zb6XIjgHtuii5dEcQuiY/8QFluA\n"
  },
  "SKFGetInstance": {
    "secretKeyType": "PBKDF2WithHmacSHA1",
    "providerName": "BC",
    "providerVersion": 1.77,
    "providerInfo": "BouncyCastle Security Provider v1.77"
  },
  "SKFGenerateSecret": {
    "algorithm": "PBKDF2WithHmacSHA1",
    "PBEKeySpecInfo": {
      "iterationCount": 1,
      "keyLength": 128,
      "password": "zb6XIjgHtuii5dEcQuiY/8QFluA\n",
      "salt": "BDBA982FAF389694"
    },
    "secretKey": "4bf14ea15d7bd3bbfcf9b7d9acc6db5c"
  },
  "SKSInit": {
    "key": "4bf14ea15d7bd3bbfcf9b7d9acc6db5c",
    "Algorithm": "AES"
  },
  "getSecretKeyInfo": {
    "algorithm": "AES",
    "keyMaterial": "4bf14ea15d7bd3bbfcf9b7d9acc6db5c"
  },
  "cryptoInitInfo": {
    "opmode": 2,
    "opmodeString": "DECRYPT",
    "key": {
      "keyClass": "javax.crypto.spec.SecretKeySpec",
      "keyAlgorithm": "AES",
      "keyFormat": "RAW",
      "keyEncoded": "4bf14ea15d7bd3bbfcf9b7d9acc6db5c"
    },
    "parameters": {
      "parameterClass": "javax.crypto.spec.IvParameterSpec",
      "parameterValue": "00000000000000000000000000000000"
    },
    "secureRandom": {
      "secureRandomClass": "java.security.SecureRandom",
      "secureRandomAlgorithm": "SHA1PRNG",
      "secureRandomProvider": "AndroidOpenSSL version 1.0"
    }
  },
  "decrypted": {
    "commonPrefs": {
      "display_rate_us_after": 0,
      "permission_event_severity": "event"
    },
    "devicePrefs": {}
  }
}

Secret key for both encrypt and decrypt operations is built upon a hardcoded key in hashTheKey method:

As an example, let's take Encryption.encrypt() method:

This method works roughly as follows:

The key for getSecretKey method is prepared by hashTheKey method:
- MessageDigest object gets instantiated with a digest algorithm (SHA1 in collected samples).
- The digest object gets updated with hardcoded key (encoded with utf-8).
- Hash computation is finished with a call to digest() method, the final hash being encoded to Base64 string (with NO_PADDING flag enabled) and converted to a char array.
The getSecretKey method instantiates SecretKeyFactory object:
- Type of the final secret key is set as PBKDF2WithHmacSHA1.
- PBEKeySpec is instantiated with the following parameters:
  - Iteration count: 1.
  - Key length: 128-bit.
  - Password: output from hashTheKey method (PBKDF2 password represented as a Java character array).
  - Salt: a value that is also hardcoded into Perenio Android application.
- The generateSecret method computes secret key from the previously listed parameters.
Java Cipher object is instantiated with the transformation AES/CBC/PKCS5Padding and is initialized with:
- Operation mode (opmode):
  - 1 = encryption
  - 2 = decryption.
- Secret key.
- Initialization vector (IV).
- Secure random (this field is initialized but not used).
Message is encrypted using Cipher.doFinal().

Encryption.decrypt() method follows the same Cipher pattern, just with opmode = 2:

Javascript code for this Frida overload is available in this repository as perenio.js.
Python reimplementation of the described encryption method is available at pythonImplementations/crypto.py.

Sample outputs of dynamic analysis script can be found in sampleLogs directory

Security Findings

A few notable considerations regarding the cryptographic methods used in the Perenio Android application:

Key and salt values are hardcoded into the Perenio Android application.
Initialization vector (IV) is initialized as a 16 byte long value of all-zeros.
Having a static key combined with all-zero IV makes AES-CBC deterministic - same plaintext inputs produce the same ciphertext outputs.
SecureRandom is instantiated but is never used to derive IV.
Password-Based Key Derivation Function 2 (PBKDF2) has an iteration count of 1:
- PBKDF2 iteration count determines how many times the hashing process of key material should be repeated.
- On the first iteration, input key is mixed with the salt and hashed.
- Subsequent iterations takes hash output of previous iteration and re-hashes it with the same method.
- As a final step, outputs of all iterations are combined (typically with a bitwise XOR) to produce the final encryption key.
- OWASP recommends 1,400,000 iterations for PBKDF2-HMAC-SHA1 (legacy) key derivation function.
- Perenio app's crypto implementation repeats the hashing process exactly 1 time, which, combined with hardcoded key, salt and all-zero IV provide no real security on the local data.
Key, derived with the aforementioned parameters, is being reused for subsequent local cryptographic operations.

Note: This is an app-only encryption method. Data in-transit is still being guarded by TLSv1.3, as well as SSL certificates pinned within Perenio Android application.

Given the points listed above, the in-app security layer reads more like an obfuscation layer rather than true random, non-deterministic encryption method.

Login sequence was intercepted using Mitmproxy and captured with Wireshark for analysis. However, network communications between Perenio Android application and the vendor's remote servers have a couple of protections:

TLSv1.3 session is negotiated before any data reaches the network.
Perenio Android application has SSL pinning enabled, meaning that only devices having Perenio's own CA certificates are trusted with the plain text data.

Tricking Android device into trusting my proxy for establishing TLSv1.3 session with it is as simple as injecting Mitmproxy's CA certificates onto Android system trust store (Bash automation script for this process can be found here). For pinned certificate bypass, Frida objection with android sslpinning disable script was used.

Note: For dynamic analysis with Frida, frida-server must be loaded and run on a target device as a daemon, so that a Frida client on host machine could have a harness that can be attached to a process for inspection and modification purposes.

A quick description of the algorithm used for capturing plain text communication between Perenio Android app and vendor's servers might be this:

Injecting Mitmproxy's CA certificate onto Android system trust store.
Push frida-server-<version>-android-arm64 onto a rooted Android device or an emulator via adb.
Start frida-server on Android device.
Set up Wi-Fi proxy on Android device to point at : of actual proxy (for example, if a proxy runs on 192.168.X.X:8080, Android device's Wi-Fi proxy needs to target 192.168.X.X:8080).
Open Perenio application on Android device.
Grab the process ID (PID) of Perenio app with uv run frida-ps -U | grep -i perenio.
Attach Frida objection to Perenio application with uv run objection -g "${pid}" explore.
Start android sslpinning disable script.
On host machine, start Mitmproxy with SSLKEYLOGFILE=/path/to/key/log/file mitmproxy --listen-port <PORT> --ssl-insecure. Saving SSL keys onto a file is necessary, because, even if Wireshark and Mitmproxy run concurrently, Wireshark does not log these keys itself. And without these keys, Wireshark can not decrypt the captured TLS sessions.
Start Wireshark (with root privileges) and start network traffic capture (capture same network interface on which the proxy runs).
Proceed to log into Perenio account.

A more comprehensive guide on HTTPS proxy setup and SSL pinning bypass can be found here.

The method described above, the following plain text login request was captured:

:method: POST
:scheme: https
:path: /auth/realms/aaa.kaa/protocol/openid-connect/token
:authority: oauth.perenio.com
tenantid: perenio
content-type: application/x-www-form-urlencoded
content-length: 144
accept-encoding: gzip
user-agent: okhttp/4.10.0

username=<email>&password=<account-password>&grant_type=password&client_id=perenio-app&client_secret=<client-secret>
.............:status: 200
date: Tue, 15 Sep 2026 14:59:55 GMT
content-type: application/json
vary: Accept-Encoding
cache-control: no-store
set-cookie: KEYCLOAK_LOCALE=; Version=1; Comment=Expiring cookie; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Max-Age=0; Path=/auth/realms/aaa.kaa/; Secure; HttpOnly
set-cookie: KC_RESTART=; Version=1; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Max-Age=0; Path=/auth/realms/aaa.kaa/; Secure; HttpOnly
x-xss-protection: 1; mode=block
pragma: no-cache
x-frame-options: SAMEORIGIN
strict-transport-security: max-age=15724800; includeSubDomains
x-content-type-options: nosniff
content-encoding: gzip

{"access_token":"<access-token>","expires_in":864000,"refresh_expires_in":51840000,"refresh_token":"<refresh-token>","token_type":"bearer","not-before-policy":0,"session_state":"<session-state>","scope":"profile email"}

A few insights from the login request:

Login request body includes a parameter list with:
- Username (email).
- Password.
- Grant type = password.
- Client ID - client is Perenio Android application.
- Client secret - (seemingly) random UUID.
The access token is valid for 10 days while refresh token expires after 600 days.
Session state differs with each login request (tested with a Python reimplementation of login request).

Heading back to the decompiled Perenio application, the login function is implemented in com.perenio.data.datasource.sections.auth.AuthRepository function:

With this information obtained from Wireshark packet capture, I decided to write a proof-of-concept Python script that POSTs a login request to an endpoint controlled by Perenio, receives an authorization token and queries hxxps[://]oauth[.]perenio[.com/auth/realms/aaa[.]kaa/users/me endpoint to get user information of my account. The script is called sampleRequest.py and can be found in pythonImplementations folder.

Script also queries a third endpoint - registrationStatus - to check whether an account with a given email address has been registered.

Response if account exists:

{
    "status": "EXISTS"
}

Response if account does not exist:

{
    "status": "NOT_EXISTS"
}

I have not tested the rate limits on this endpoint, but it potentially could be used to enumerate existing Perenio accounts.

Sample response to login request:

{
    "access_token": "<access-token>",
    "expires_in": 864000,
    "refresh_expires_in": 51840000,
    "refresh_token": "<refresh-token>",
    "token_type": "bearer",
    "not-before-policy": 0,
    "session_state": "<session-state>",
    "scope": "profile email"
}

Sample response to user information query:

{
    "uid": "<user-id>",
    "countryCode": "LT",
    "email": "<email>",
    "language": "EN",
    "nickname": "<nickname>"
}

This also further proves that encryption methods described previously are local-only as these HTTP requests and responses contain plain text body - the encryption aspect is handed to TLSv1.3 and pinned SSL certificates.

The script can also be found as sampleRequest.py in pythonImplementations folder

Analysis of Media Stream (Audio/Video)

Perenio Peifc01 IP camera captures and transmits both audio and video streams. A sample stream was collected using Comfast CF-922AC USB Wi-Fi adapter in monitor mode.

Packet collection process can be described as follows:

Figure out adapter's network interface:
```
ip a
```
Figure out a wireless channel of relevant Wi-Fi network:
```
nmcli device wifi list
```

Restart Comfast Wi-Fi adapter in monitor mode:

sudo airmon-ng start <comfast-interface> <channel-number>

Start Wireshark and start packet capture on <comfast-interface>mon interface.
Connect IP camera and smartphone to Wi-Fi (Important: connect camera and smartphone to Wi-Fi after starting packet capture - Wireshark needs to capture 4-way handshake to derive cryptographic keys for Wi-Fi network traffic decryption).
Start Perenio application on Android device and access IP camera's video stream - Wireshark should capture this data as of now.

Wireshark shows heavy UDP traffic on ports 50612, 54386 and 54431:

The datagrams themselves seem to contain highly structured data - decoding them as Real-time Transport Protocol (RTP) on Wireshark with Right click on UDP packet -> Decode as -> RTP reveals that the captured UDP data is audio/video stream relay between Perenio Peifc01 IP camera and a smartphone via vendor controlled Amazon AWS EC2 instance. The following structure can be inferred from this packet capture:

Port number	Protocol	Purpose
50612	RTP over UDP	Audio stream `IP camera -> EC2 instance`
54386	RTP over UDP	Video stream `IP camera -> EC2 instance`
54431	SRTP over UDP	Stream relay `EC2 instance -> smartphone`

IP camera sends video/audio streams as plaintext RTP data over the network to an Amazon AWS EC2 instance, controlled by the vendor. EC2 instance then relays combined audio/video stream to Android application via SRTP (Secure RTP) channel.

RTP Packet Structure

RTP header, as per RFC3550 specification, has the following structure:

Version (V - 2 bits): identifies RTP version.
Padding (P - 1 bit): if set, the packet contains one or more padding octets at the end that are not part of payload.
Extension (X - 1 bit): if set, fixed header must be followed by exactly one header extension.
CSRC count (CC - 4 bits): number of CSRC identifiers that follow fixed header.
Marker (M - 1 bit): intended to allow significant events (e.g. frame boundaries) to be marked in packet stream.
Payload type (PT - 7 bits): format of RTP payload.
Sequence number (16 bits): random number that increments by one for each RTP data packet.
Timestamp (32 bits): sampling instant of the first octet in RTP data packet.
Synchronization source (SSRC) identifier (32bits): identifies a synchronization source that should be selected randomly.

Visual RTP header representation from RFC3550 specification is presented below:

After a fixed header and CSRC identifiers (if present, RTP packet can have 0 to 15 32-bit long items as CSRC list entries right after SSRC), payload is added to the RTP packet. If padding is set to 1, a certain amount of padding bytes are appended to the packet after payload. Count of padding bytes is stored as a last byte of RTP packet (count includes this last byte as well).

Video Encoding

As a video stream codec, H.264 (also known as Advanced Video Coding - AVC) is used. When a video is encoded with a standard like H.264, the stream is sliced into Network Abstraction Layer (NAL) units for reliable data transmission over a network. However, RTP over UDP has a limit for how large a single network packet can be. This limit is called Maximum Transmission Unit (MTU) and for Ethernet/Wi-Fi networks it usually is 1500 bytes, including packet headers. Accounting for Ethernet/IPv4/UDP/RTP headers leaves 1460 bytes at most for the payload (additional header information is added to RTP packet if the packet has CSRC identifiers and/or is being sent via VPN/IPSec tunnel).

Anyways, a large NAL unit can exceed single MTU, which means that such a NAL unit has to be split into multiple RTP packets for a successful transmission. For this purpose, H.264 has a defined Fragmentation Unit (FU), comprised of 1-byte FU Indicator and 1-byte FU Header.

FU Indicator

FU Indicator is constructed against RFC 6184 standard, section 1.3:

Bits	Name	Description
0	F	forbidden_zero_bit
1-2	NRI	nal_ref_idc
3-7	Type	nal_unit_type

Forbidden zero bit: normally equals 0. If this bit is set to 1, it indicates that a syntax violation / bit error was detected.
NAL reference IDC (NRI): when it equals 0, it means that this NAL unit is not used for reference picture reconstruction. Greater values indicate that NAL unit is required to maintain integrity of reference pictures.
NAL unit type. For example, Fragmentation Unit A (FU-A) has an unit type of 28.

Visual FU Indicator structure from RFC 6184 standard, section 1.3 is presented below:

FU Header

FU Header byte is present only on NAL Fragmentation Units and is constructed against RFC 6184 standard, section 5.8:

Bits	Name	Description
0	S	Start bit of fragmented NAL unit
1	E	End bit of fragmented NAL unit
2	R	Reserved bit - must equal 0 and ignored by the receiver
3-7	Type	NAL unit type

Visual FU Header structure from RFC 6184 standard, section 5.8 is presented below:

When a NAL unit is fragmented into FU-A (and FU-B) units, the original one-byte NAL header is reconstructed by preserving the F and NRI bits from the FU indicator and taking the NAL-unit type from the FU header:

(FU Identifier & 0xE0) | (FU Header & 0x1F)

This operation swaps fragmentation unit type (28 for FU-A and 29 for FU-B) with the type of actual video data in NALU.

Stream Reconstruction Script

Stream reconstruction script is available as streamExtraction.py script in pythonImplementations folder.

As of now, only the relevant features for Perenio Peifc01 IP camera's stream reconstruction are included in this script:

Fragmentation Unit A (FU-A) reassembly into Network Abstraction Layer (NAL) unit.
Reassembling RTP L16 (as defined in RFC 3551, section 4.5.11) raw uncompressed audio data samples into a .wav audio file.
Parsing fixed header fields of RTP packet.

Features that are not included in the script:

Fragmentation Unit B (FU-B) reassembly into Network Abstraction Layer (NAL) unit.
RTP padding removal, when it exists.
Parsing (optional) CSRC fields of a RTP header.
Encoding separate audio/video streams into a single media file.
Audio / video synchronization and frame timing for muxing.

The script, however, produces playable audio and video files, with a reconstructed video frame presented below:

Conclusion

Key points to summarize the security research of Perenio application:

Cryptographic method analysis of Perenio Smart: Home and Office Android application revealed a few issues with how local data encryption is implemented.
After successful login to Perenio account, accessToken that is valid for 10 days is issued while the validity period of refreshToken is 600 days.
Perenio Peifc01 IP camera sends RTP packets over UDP with unencrypted audio and video streams to an Amazon AWS EC2 instance, meaning that the network traffic could be captured and audio / video data from Peifc01 IP camera be reconstructed by someone who has:
- Wi-Fi Pre-Shared Key (PSK) for the Wireless Local Area Network (WLAN), where Peifc01 IP camera resides.
- Wi-Fi adapter in monitor mode.
- Captures 4-way handshake as Peifc01 IP camera connects to the network.
AWS EC2 instance relays the encoded file with combined audio/video to the Perenio Android application via Secure RTP (SRTP).

Building Payment Flows in Android: Lessons from Real Fintech Apps

Wed, 23 Sep 2026 09:35:18 +0000

Building Payment Flows in Android: Production Patterns from Fintech Applications

Subtitle: Architectural patterns and state management strategies for reliable payment flows at scale

Introduction

Over the past months, I've been building and refining payment systems at scale. Every architectural decision compounds over time, and payment flows demand particular attention to state management, error handling, and offline resilience.

This article documents the patterns that have proven effective in production fintech applications. These aren't theoretical approaches—they represent lessons learned from handling millions of transactions and the edge cases that accompany them.

Why Payment Flows Require Specialized Architecture

Most mobile applications tolerate a certain degree of architectural looseness. A user can restart the app if something fails. Recovery is straightforward.

Payment flows operate under different constraints:

State Ambiguity is Costly
When a user initiates a payment, your application must maintain absolute clarity about its status: submitted, pending, failed, queued offline. If this state is unclear, the user is equally uncertain, leading to duplicate submissions or lost transactions.

Race Conditions Have Financial Consequences
A user confirms payment and immediately navigates away. Your retry logic must account for this without resubmitting the payment or losing the transaction record.

Network Reliability Cannot Be Assumed
In many markets, network interruptions occur mid-transaction. Your system must handle incomplete requests gracefully—queuing the transaction locally and retrying when connectivity returns.

Offline-First Is Essential
Users may initiate transactions without active connectivity. The application must queue payments locally, survive process termination, and submit reliably when network becomes available.

This is why Clean Architecture and MVI pattern implementation is not optional for payment flows—it becomes a structural guarantee that state remains traceable and predictable.

Architectural Foundation

For context on the underlying architecture, see Clean Architecture in Android: A Real-World Guide.

The structure we use:

:domain — Pure Kotlin business logic without Android dependencies
:data — Repository layer managing offline queues, network calls, and persistence
:feature:payment — MVI implementation containing Intent, UiState, ViewModel, and UI layers

This separation ensures business logic can be tested independently of Android runtime, catching state-related bugs before deployment.

Pattern 1: Payment Confirmation Flow with Explicit State

The MVI Contract

sealed class PaymentConfirmationIntent {
    data class LoadPaymentDetails(val paymentId: String) : PaymentConfirmationIntent()
    object ConfirmPayment : PaymentConfirmationIntent()
    object RetryPayment : PaymentConfirmationIntent()
    object CancelPayment : PaymentConfirmationIntent()
    object DismissError : PaymentConfirmationIntent()
}

data class PaymentConfirmationUiState(
    val paymentDetails: PaymentDetails? = null,
    val isLoading: Boolean = false,
    val isConfirming: Boolean = false,
    val error: PaymentError? = null,
    val isOffline: Boolean = false,
    val confirmationStatus: ConfirmationStatus = ConfirmationStatus.Idle,
) {
    enum class ConfirmationStatus {
        Idle,
        AwaitingUserConfirmation,
        Processing,
        Success,
        Failed,
        OfflineQueued,
    }
}

sealed class PaymentConfirmationEffect {
    object NavigateToSuccess : PaymentConfirmationEffect()
    object NavigateToFailure : PaymentConfirmationEffect()
    object NavigateBack : PaymentConfirmationEffect()
}

Structural Benefits:

The ConfirmationStatus.OfflineQueued state explicitly represents the condition where payment has been submitted locally and awaits network availability. This eliminates ambiguity about whether a transaction was successfully queued.

Each Intent represents a discrete user action with no overlap, preventing state collisions. The isOffline flag as part of UiState ensures the UI layer can respond to network conditions with appropriate messaging.

ViewModel Implementation

@HiltViewModel
class PaymentConfirmationViewModel @Inject constructor(
    private val paymentRepository: PaymentRepository,
    private val offlinePaymentQueue: OfflinePaymentQueue,
    private val networkManager: NetworkManager,
) : ViewModel() {

    private val _state = MutableStateFlow<PaymentConfirmationUiState>(
        PaymentConfirmationUiState()
    )
    val state: StateFlow<PaymentConfirmationUiState> = _state.asStateFlow()

    fun processIntent(intent: PaymentConfirmationIntent) {
        when (intent) {
            is PaymentConfirmationIntent.LoadPaymentDetails -> 
                loadPaymentDetails(intent.paymentId)
            is PaymentConfirmationIntent.ConfirmPayment -> 
                confirmPayment()
            is PaymentConfirmationIntent.RetryPayment -> 
                retryPayment()
            is PaymentConfirmationIntent.CancelPayment -> 
                cancelPayment()
            is PaymentConfirmationIntent.DismissError -> 
                dismissError()
        }
    }

    private fun confirmPayment() {
        viewModelScope.launch {
            _state.update { it.copy(isConfirming = true) }

            try {
                if (!networkManager.isConnected()) {
                    val queuedPayment = offlinePaymentQueue.enqueue(
                        _state.value.paymentDetails ?: return@launch
                    )
                    _state.update {
                        it.copy(
                            isConfirming = false,
                            confirmationStatus = 
                                PaymentConfirmationUiState.ConfirmationStatus.OfflineQueued,
                        )
                    }
                    return@launch
                }

                val result = paymentRepository.submitPayment(
                    _state.value.paymentDetails!!
                )

                when (result) {
                    is PaymentResult.Success -> {
                        _state.update {
                            it.copy(
                                isConfirming = false,
                                confirmationStatus = 
                                    PaymentConfirmationUiState.ConfirmationStatus.Success,
                            )
                        }
                    }
                    is PaymentResult.Failure -> {
                        _state.update {
                            it.copy(
                                isConfirming = false,
                                error = result.error,
                                confirmationStatus = 
                                    PaymentConfirmationUiState.ConfirmationStatus.Failed,
                            )
                        }
                    }
                }
            } catch (e: Exception) {
                _state.update {
                    it.copy(
                        isConfirming = false,
                        error = PaymentError.Unknown(e.message ?: "Unknown error"),
                        confirmationStatus = 
                            PaymentConfirmationUiState.ConfirmationStatus.Failed,
                    )
                }
            }
        }
    }

    private fun retryPayment() {
        confirmPayment()
    }

    private fun dismissError() {
        _state.update { it.copy(error = null) }
    }

    private fun loadPaymentDetails(paymentId: String) {
        viewModelScope.launch {
            _state.update { it.copy(isLoading = true) }
            try {
                val details = paymentRepository.getPaymentDetails(paymentId)
                _state.update {
                    it.copy(
                        isLoading = false,
                        paymentDetails = details,
                        isOffline = !networkManager.isConnected(),
                    )
                }
            } catch (e: Exception) {
                _state.update {
                    it.copy(
                        isLoading = false,
                        error = PaymentError.LoadFailed(
                            e.message ?: "Failed to load"
                        ),
                    )
                }
            }
        }
    }

    private fun cancelPayment() {
        // Navigate back without submission
    }
}

Key Implementation Details:

Network connectivity is checked before submission
Offline state triggers local queueing with explicit status update
Exception handling updates UI state rather than propagating errors
All state transitions are explicit and traceable

UI Layer

@Composable
fun PaymentConfirmationScreen(
    viewModel: PaymentConfirmationViewModel,
    paymentId: String,
    onSuccess: () -> Unit,
    onFailure: () -> Unit,
    onBack: () -> Unit,
) {
    val state by viewModel.state.collectAsState()

    LaunchedEffect(Unit) {
        viewModel.processIntent(
            PaymentConfirmationIntent.LoadPaymentDetails(paymentId)
        )
    }

    LaunchedEffect(state.confirmationStatus) {
        when (state.confirmationStatus) {
            PaymentConfirmationUiState.ConfirmationStatus.Success -> 
                onSuccess()
            PaymentConfirmationUiState.ConfirmationStatus.Failed -> 
                onFailure()
            else -> {}
        }
    }

    Box(modifier = Modifier.fillMaxSize()) {
        when {
            state.isLoading -> {
                CircularProgressIndicator(
                    modifier = Modifier.align(Alignment.Center)
                )
            }
            state.paymentDetails != null -> {
                Column(
                    modifier = Modifier
                        .fillMaxSize()
                        .padding(16.dp),
                    verticalArrangement = Arrangement.spacedBy(16.dp),
                ) {
                    PaymentDetailsCard(state.paymentDetails)

                    if (state.isOffline) {
                        OfflineWarningBanner()
                    }

                    state.error?.let { error ->
                        ErrorBanner(
                            message = error.message,
                            onDismiss = {
                                viewModel.processIntent(
                                    PaymentConfirmationIntent.DismissError
                                )
                            }
                        )
                    }

                    Spacer(modifier = Modifier.weight(1f))

                    when (state.confirmationStatus) {
                        PaymentConfirmationUiState.ConfirmationStatus
                            .AwaitingUserConfirmation -> {
                            ConfirmationButtons(viewModel, onBack)
                        }
                        PaymentConfirmationUiState.ConfirmationStatus
                            .OfflineQueued -> {
                            Button(
                                onClick = { onBack() },
                                modifier = Modifier.fillMaxWidth(),
                            ) {
                                Text("Done")
                            }
                        }
                        PaymentConfirmationUiState.ConfirmationStatus.Failed -> {
                            Button(
                                onClick = {
                                    viewModel.processIntent(
                                        PaymentConfirmationIntent.RetryPayment
                                    )
                                },
                                modifier = Modifier.fillMaxWidth(),
                            ) {
                                Text("Retry")
                            }
                        }
                        else -> {}
                    }
                }
            }
            state.error != null -> {
                ErrorScreen(
                    error = state.error,
                    onRetry = {
                        viewModel.processIntent(
                            PaymentConfirmationIntent
                                .LoadPaymentDetails(paymentId)
                        )
                    },
                    onBack = onBack,
                )
            }
        }
    }
}

@Composable
private fun OfflineWarningBanner() {
    Card(
        modifier = Modifier.fillMaxWidth(),
        colors = CardDefaults.cardColors(
            containerColor = Color(0xFFFFF3CD)
        ),
    ) {
        Row(
            modifier = Modifier
                .fillMaxWidth()
                .padding(12.dp),
            horizontalArrangement = Arrangement.spacedBy(8.dp),
            verticalAlignment = Alignment.CenterVertically,
        ) {
            Icon(
                imageVector = Icons.Default.Warning,
                contentDescription = null,
                tint = Color(0xFFFF9800),
            )
            Text(
                text = "You are offline. Your payment will be submitted when connectivity is restored.",
                fontSize = 14.sp,
                modifier = Modifier.weight(1f),
            )
        }
    }
}

Pattern 2: Offline Payment Queue with Persistence

Local queueing with durable storage is essential for offline-first applications.

// domain/payment/OfflinePaymentQueue.kt

data class QueuedPayment(
    val id: String,
    val payment: PaymentDetails,
    val timestamp: Long,
    val retryCount: Int = 0,
    val status: QueueStatus = QueueStatus.Pending,
) {
    enum class QueueStatus {
        Pending,
        Retrying,
        Submitted,
        Failed,
    }
}

interface OfflinePaymentQueue {
    suspend fun enqueue(payment: PaymentDetails): QueuedPayment
    suspend fun getAll(): List<QueuedPayment>
    suspend fun getById(id: String): QueuedPayment?
    suspend fun remove(id: String)
    suspend fun updateStatus(id: String, status: QueueStatus)
    suspend fun incrementRetry(id: String)
}

// data/payment/OfflinePaymentQueueImpl.kt

@Singleton
class OfflinePaymentQueueImpl @Inject constructor(
    private val paymentDao: PaymentQueueDao,
) : OfflinePaymentQueue {

    override suspend fun enqueue(payment: PaymentDetails): QueuedPayment {
        val queued = QueuedPayment(
            id = UUID.randomUUID().toString(),
            payment = payment,
            timestamp = System.currentTimeMillis(),
        )
        paymentDao.insert(queued.toEntity())
        return queued
    }

    override suspend fun getAll(): List<QueuedPayment> {
        return paymentDao.getAll().map { it.toDomain() }
    }

    override suspend fun updateStatus(
        id: String,
        status: QueueStatus
    ) {
        paymentDao.updateStatus(id, status.name)
    }

    override suspend fun remove(id: String) {
        paymentDao.delete(id)
    }

    override suspend fun incrementRetry(id: String) {
        paymentDao.incrementRetry(id)
    }

    override suspend fun getById(id: String): QueuedPayment? {
        return paymentDao.getById(id)?.toDomain()
    }
}

Background synchronization handles submission when connectivity is restored:

// data/payment/PaymentSyncWorker.kt

class PaymentSyncWorker @Inject constructor(
    context: Context,
    params: WorkerParameters,
    private val offlineQueue: OfflinePaymentQueue,
    private val paymentRepository: PaymentRepository,
) : CoroutineWorker(context, params) {

    override suspend fun doWork(): Result {
        return try {
            val queuedPayments = offlineQueue.getAll()
                .filter { it.status == QueueStatus.Pending }

            queuedPayments.forEach { queued ->
                try {
                    offlineQueue.updateStatus(
                        queued.id,
                        QueueStatus.Retrying
                    )

                    val result = paymentRepository.submitPayment(
                        queued.payment
                    )

                    when (result) {
                        is PaymentResult.Success -> {
                            offlineQueue.updateStatus(
                                queued.id,
                                QueueStatus.Submitted
                            )
                            offlineQueue.remove(queued.id)
                        }
                        is PaymentResult.Failure -> {
                            if (queued.retryCount < MAX_RETRIES) {
                                offlineQueue.incrementRetry(queued.id)
                            } else {
                                offlineQueue.updateStatus(
                                    queued.id,
                                    QueueStatus.Failed
                                )
                            }
                        }
                    }
                } catch (e: Exception) {
                    if (queued.retryCount < MAX_RETRIES) {
                        offlineQueue.incrementRetry(queued.id)
                    } else {
                        offlineQueue.updateStatus(
                            queued.id,
                            QueueStatus.Failed
                        )
                    }
                }
            }

            Result.success()
        } catch (e: Exception) {
            Result.retry()
        }
    }

    companion object {
        private const val MAX_RETRIES = 5
        const val WORK_NAME = "payment_sync"
    }
}

// Schedule in application startup:
// WorkManager.getInstance(context).enqueueUniquePeriodicWork(
//     PaymentSyncWorker.WORK_NAME,
//     ExistingPeriodicWorkPolicy.KEEP,
//     PeriodicWorkRequestBuilder<PaymentSyncWorker>(
//         15, TimeUnit.MINUTES
//     ).build()
// )

Benefits of This Approach:

Payment data persists across process termination
Retry logic respects maximum attempt limits
Each payment has a unique identifier preventing duplicate submissions
Status transitions are durable and traceable

Pattern 3: Biometric Authentication for Payment Confirmation

Biometric authentication integrates as a discrete state within the payment flow:

sealed class BiometricAuthIntent {
    object AuthenticateWithBiometric : BiometricAuthIntent()
    object CancelBiometric : BiometricAuthIntent()
    object RetryBiometric : BiometricAuthIntent()
}

data class BiometricAuthUiState(
    val isAuthenticating: Boolean = false,
    val authResult: BiometricAuthResult? = null,
    val error: BiometricError? = null,
) {
    sealed class BiometricAuthResult {
        object Success : BiometricAuthResult()
        object Failure : BiometricAuthResult()
        object Cancelled : BiometricAuthResult()
    }
}

@HiltViewModel
class BiometricAuthViewModel @Inject constructor(
    private val biometricManager: BiometricManager,
) : ViewModel() {

    private val _state = MutableStateFlow<BiometricAuthUiState>(
        BiometricAuthUiState()
    )
    val state: StateFlow<BiometricAuthUiState> = _state.asStateFlow()

    fun processIntent(intent: BiometricAuthIntent) {
        when (intent) {
            BiometricAuthIntent.AuthenticateWithBiometric -> authenticate()
            BiometricAuthIntent.CancelBiometric -> cancel()
            BiometricAuthIntent.RetryBiometric -> authenticate()
        }
    }

    private fun authenticate() {
        viewModelScope.launch {
            _state.update { it.copy(isAuthenticating = true) }

            try {
                val result = biometricManager.authenticate()
                _state.update {
                    it.copy(
                        isAuthenticating = false,
                        authResult = result,
                    )
                }
            } catch (e: BiometricException) {
                _state.update {
                    it.copy(
                        isAuthenticating = false,
                        error = BiometricError.AuthenticationFailed(
                            e.message ?: "Authentication failed"
                        ),
                    )
                }
            }
        }
    }

    private fun cancel() {
        biometricManager.cancel()
        _state.update {
            it.copy(
                isAuthenticating = false,
                authResult = BiometricAuthUiState.BiometricAuthResult
                    .Cancelled,
            )
        }
    }
}

Biometric authentication state remains consistent with the MVI pattern rather than introducing separate concerns.

Transaction Flow Example

Consider a complete transaction lifecycle:

User initiates payment confirmation
App checks network connectivity
If offline: payment queued locally with OfflineQueued status
If online: payment submitted to server
On network restoration: background worker processes offline queue
Each queued payment retried up to 5 times before marking failed
User notified of final status through UI state updates

This approach ensures:

No state ambiguity at any point
Network interruptions don't result in lost transactions
Duplicate submissions are prevented
Process termination doesn't destroy payment records

Open-Source Implementation

These patterns are available in production-ready form:

clean-architecture-android — Foundation template with Clean Architecture, MVI, and Jetpack Compose
fintech-mobile-patterns-android — Payment flow implementations with offline queuing, error handling, and authentication patterns

Both repositories include complete implementations with testing examples.

Conclusion

Payment flow architecture demands explicit state management and thoughtful error handling. The patterns discussed—explicit state enums, offline queuing with persistence, and MVI-based architecture—provide structural guarantees that reduce the likelihood of state-related bugs.

These approaches have proven effective at production scale. They prioritize clarity of state over brevity of code, understanding that payment systems benefit more from predictability than elegance.

Additional Resources

Android CI/CD for Beginners — Part 1: Introduction

Tue, 22 Sep 2026 17:12:07 +0000

Stop building everything manually. Learn how modern Android teams automate their development workflow

This series is designed to provide a complete understanding of CI/CD for Android development. In Part 1, we’ll introduce the fundamentals of CI/CD, explore what it is, why it matters, and how it’s used in Android app development.

CI/CD (Continuous Integration and Continuous Delivery/Deployment) is a set of practices that automate repetitive tasks in the software development process, such as building, testing, and releasing applications.

Instead of manually performing these tasks every time you make a change, a CI/CD pipeline executes them automatically whenever predefined events occur, such as pushing code to a Git repository.

How can CI/CD automate tasks in Android development?
CI/CD automates many of the repetitive tasks involved in the Android development lifecycle. Instead of running these steps manually every time you make a change, they can be executed automatically whenever code is pushed to your repository.

With a CI/CD pipeline, your Android app can be automatically:

Built using Gradle.
Analyzed for code quality with Android Lint.
Tested by running unit and instrumentation tests.
Packaged into a signed or unsigned APK or Android App Bundle (AAB).
Distributed to testers or prepared for release to the Google Play Store.
You might be wondering: Why do we need to automate these tasks?

In real-world Android projects, multiple developers often work on the same codebase. Every new feature, bug fix, or improvement is usually submitted as a pull request (PR).

Before those changes are merged, the team needs to ensure they meet the project’s quality standards and don’t introduce bugs or break existing functionality.

Manually building the app, running lint checks, executing tests, and verifying every pull request can quickly become repetitive and time-consuming, especially as the project grows.

This is where CI/CD becomes valuable. Whenever a pull request is opened or updated, a CI pipeline can automatically build the app, run lint checks, execute unit and instrumentation tests, and report whether all checks have passed.

If any step fails, developers are notified immediately, allowing issues to be fixed before the changes are merged.

Once all the automated checks succeed, the CD pipeline can take over by generating an APK or App Bundle and distributing it to testers or preparing it for release.

This eliminates many manual steps, speeds up the development process, and helps maintain a stable and reliable codebase.

Common CI/CD Terminology
Before we start building our first CI/CD pipeline, it’s important to understand some common terms you’ll encounter throughout this series. These concepts are not exclusive to Android development, they’re used across many CI/CD platforms. We’ll explore how these ideas come together in practice in the upcoming sections.

Pipeline
A pipeline is the complete automated process that runs after a specific event, such as pushing code to a Git repository or opening a pull request. A pipeline can build your app, run tests, generate an APK, and even distribute it to testers — all without manual intervention.

Think of a pipeline as a sequence of automated tasks executed in a predefined order.

Workflow
In GitHub Actions, a pipeline is defined using a workflow. A workflow is a YAML (.yml or .yaml) file stored inside the .github/workflows directory of your project.

It describes what should happen, when it should happen, and how it should be executed.

A repository can contain multiple workflows, each responsible for different tasks. For example, one workflow may run tests for every pull request, while another creates a release build whenever a new version is published.

Event (Trigger)
A workflow doesn’t run on its own — it needs an event, also known as a trigger.

Common triggers include:

Pushing code to a branch (push)
Opening or updating a pull request (pull_request)
Manually starting a workflow (workflow_dispatch)
Creating a release (release)
Whenever one of these events occurs, GitHub Actions starts the corresponding workflow.

Runner
A runner is the machine responsible for executing your workflow.

GitHub provides hosted runners running Linux, Windows, and macOS. For Android projects, Linux runners are commonly used because they provide a fast and cost-effective environment for building Android applications.

You can also configure your own self-hosted runner if you need custom hardware or software.

Job
A job is a collection of related tasks executed on the same runner.

For example, one job might build the Android app, while another runs unit tests. Multiple jobs can run sequentially or in parallel, depending on how the workflow is configured.

Step
A step is a single task inside a job.

Examples of steps include:

Checking out the repository
Setting up Java
Installing Android dependencies
Running Gradle commands
Uploading the generated APK
A job is simply a sequence of steps executed one after another.

Action
An Action is a reusable piece of automation that performs a specific task.

Instead of writing everything from scratch, you can use actions created by GitHub or the community.

For example:

actions/checkout downloads your repository onto the runner.
actions/setup-java installs and configures Java.
actions/upload-artifact uploads build outputs such as APKs or test reports.
Actions make workflows shorter, cleaner, and easier to maintain.

Artifact
An artifact is a file generated during a workflow that you want to keep after the workflow finishes.

In Android projects, common artifacts include:

APK files
Android App Bundles (AAB)
Lint reports
Unit test reports
Code coverage reports
Artifacts can be downloaded later for testing, debugging, or distribution.

GitHub Actions
Throughout this series, we’ll use GitHub Actions as our CI/CD platform.

GitHub Actions is GitHub’s built-in automation service that allows you to create workflows using YAML files. It automatically responds to events in your repository, runs your workflows on runners, and reports the results all directly within GitHub.

Now that you’re familiar with these core concepts, we’ll start creating our first Android CI workflow in the next part of this series.

That all it for now…
Lets stop here for now as this is already too much if your just starting out

Now that you understand the purpose of CI/CD and the terminology behind it, it’s time to build your first pipeline.

In Part 2, we’ll set up GitHub Actions, create our first workflow, and automatically build an Android application whenever code is pushed to GitHub.

👋Bye!!!

Android System Back Button Closes the App After Upgrading to Target SDK 36 — React Native Fix

Tue, 22 Sep 2026 04:30:24 +0000

If you're maintaining a React Native Android application and recently upgraded your project to target SDK 36 (Android 16), you may encounter an unexpected navigation issue:

Pressing the Android system back button closes the app instead of navigating to the previous screen.

This can be particularly confusing when React Navigation is already configured correctly and the same navigation flow works perfectly on older Android target SDK versions.

This article explains what changed, how to identify the issue, the workaround I used, and what you should consider for a proper Android 16 migration.

The Problem

After upgrading the Android project from an older target SDK to:

targetSdkVersion = 36

the app started behaving differently when using the Android system back button.

For example, suppose the navigation stack is:

Home
  ↓
Products
  ↓
Product Details

When the user presses the Android system back button from Product Details, the expected behavior is:

Product Details
        ↓
    Products

Instead, the application could close.

Interestingly, navigation using React Navigation itself continued to work:

navigation.goBack();

The issue was specifically related to the Android system back event.

Environment

The issue was observed in a React Native application with a setup similar to:

React Native
React Navigation
Android SDK 36
Target SDK 36

The important change was upgrading the Android target SDK to API level 36, corresponding to Android 16.

Why Does This Happen?

The important part of the migration is the Android back-navigation change.

Android has been moving away from the older:

onBackPressed()

mechanism toward the newer:

OnBackInvokedDispatcher

and predictive back navigation APIs.

With newer Android versions and target SDK requirements, applications need to properly participate in the newer back-navigation system.

This can expose compatibility issues in applications or libraries that still rely on the older back handling mechanism.

In a React Native application, the Android system back event eventually needs to be correctly propagated into the React Native / React Navigation layer.

If that doesn't happen, Android may interpret the back action as:

No navigation handler
        ↓
Finish current Activity
        ↓
App closes

instead of:

System Back
     ↓
React Native Back Handler
     ↓
React Navigation
     ↓
Previous screen

How I Identified the Problem

The first thing I checked was whether React Navigation itself was working.

Navigation from the application was working correctly:

navigation.navigate("ProductDetails");

and programmatic back navigation also worked:

navigation.goBack();

The problem only occurred when pressing the physical/system Android back button.

I also checked whether the application was closing directly from the Home screen.

That behavior is expected:

Home
 ↓
Android Back
 ↓
App exits

The actual problem was:

Home
 ↓
Product List
 ↓
Product Details
 ↓
Android Back
 ↓
App exits ❌

instead of:

Home
 ↓
Product List
 ↓
Product Details
 ↓
Android Back
 ↓
Product List ✅

This distinction is important when debugging Android back navigation.

The AndroidManifest Configuration

The Android application can control the behavior of the newer back system using:

android:enableOnBackInvokedCallback

For example:

<application
    android:name=".MainApplication"
    android:label="@string/app_name"
    android:icon="@mipmap/ic_launcher"
    android:enableOnBackInvokedCallback="false">

In my case, setting:

android:enableOnBackInvokedCallback="false"

worked as a temporary workaround.

After adding this configuration, the Android system back button once again started navigating to the previous React Navigation screen instead of immediately closing the application.

Why Does `false` Work?

Setting:

android:enableOnBackInvokedCallback="false"

essentially disables the application's participation in the newer OnBackInvokedDispatcher behavior.

This allows the application to continue using the older back handling path.

Conceptually:

Without the workaround

Android System Back
        ↓
OnBackInvokedDispatcher
        ↓
React Native / Navigation handler
        ↓
❌ Handler not properly triggered
        ↓
Activity finishes
        ↓
App closes

With the temporary workaround

Android System Back
        ↓
Legacy back handling
        ↓
React Native BackHandler
        ↓
React Navigation
        ↓
Previous screen

So the workaround doesn't really "fix" predictive back support.

It tells Android to avoid the newer callback behavior for this application.

Is `enableOnBackInvokedCallback="false"` the Permanent Fix?

Not necessarily.

This is an important distinction.

If your application is targeting Android 16, you should ideally investigate whether your React Native version and navigation dependencies properly support Android's newer back-navigation behavior.

Using:

android:enableOnBackInvokedCallback="false"

can be useful as a compatibility workaround while migrating, but it should not automatically be considered the final Android 16 solution.

The long-term goal should be:

Android 16
      ↓
Predictive Back
      ↓
OnBackInvokedDispatcher
      ↓
React Native
      ↓
React Navigation

working correctly.

Check Your React Native Version

Before adding application-level workarounds, check the React Native version:

npm list react-native

or:

yarn why react-native

Also check React Navigation:

npm list @react-navigation/native

For example:

react-native
@react-navigation/native
@react-navigation/native-stack
@react-navigation/bottom-tabs

Older combinations may have different levels of Android predictive-back support.

It's important to evaluate the complete dependency chain rather than changing only the AndroidManifest.

Check Your `MainActivity`

Also inspect your Android MainActivity.

A typical React Native application may have something similar to:

public class MainActivity extends ReactActivity {

    @Override
    protected String getMainComponentName() {
        return "MyApp";
    }
}

If your application has custom back handling, search the Android project for:

onBackPressed

For example:

grep -R "onBackPressed" android/

Also search for:

OnBackInvokedDispatcher

and:

OnBackInvokedCallback

This helps identify whether custom native code is interfering with the new Android back-navigation mechanism.

Check React Native `BackHandler`

React Native applications can listen for Android back events using:

import { BackHandler } from "react-native";

For example:

useEffect(() => {
  const subscription = BackHandler.addEventListener(
    "hardwareBackPress",
    () => {
      navigation.goBack();
      return true;
    }
  );

  return () => subscription.remove();
}, [navigation]);

However, don't add this globally just to hide the problem.

React Navigation normally handles Android back navigation for its navigation stack.

Adding multiple global BackHandler listeners can introduce new problems such as:

Back event being consumed too early
Incorrect navigation
Screens being popped multiple times
Modals not closing correctly
Navigation stack becoming inconsistent

So first determine whether the underlying Android back event is reaching React Native correctly.

A Useful Debugging Test

You can temporarily add a BackHandler listener to determine whether React Native receives the system back event:

useEffect(() => {
  const subscription = BackHandler.addEventListener(
    "hardwareBackPress",
    () => {
      console.log("ANDROID BACK EVENT RECEIVED");

      return false;
    }
  );

  return () => subscription.remove();
}, []);

Then navigate to a screen and press the Android system back button.

If you see:

ANDROID BACK EVENT RECEIVED

then the event is reaching React Native.

If the app closes without the event reaching your JavaScript handler, the problem is likely further down in the Android back-dispatching path.

This is a useful way to separate:

Android back event problem

from:

React Navigation configuration problem

Don't Confuse Home Screen Behavior With a Bug

One important testing detail:

If the user is already on the root screen:

Home

pressing Android Back is normally expected to exit the application.

For example:

Home
 ↓
Android Back
 ↓
App closes

That alone isn't evidence of a problem.

The important test is:

Home
 ↓
Screen A
 ↓
Screen B
 ↓
Android Back

Expected:

Screen B
 ↓
Screen A

If instead:

Screen B
 ↓
App closes

then back navigation is not being handled correctly.

Testing Checklist After Target SDK 36 Upgrade

After upgrading to API 36, I recommend testing all of these scenarios.

Home → List → Details

Press system Back.

Expected:

Details → List

Home → A → B → C

Press Back repeatedly.

Expected:

C → B → A → Home

3. Root screen

Home

Press Back.

Expected:

App exits

Open a modal and press Back.

Expected:

Modal closes

instead of:

App exits

5. Bottom tabs

Test:

Tab A → Tab B → Screen

and verify that system Back behaves consistently with your navigation design.

6. Authentication flow

Test:

Login → OTP → Home

and make sure Back doesn't allow users to incorrectly return to authentication screens.

7. Deep links

Test:

Deep Link → Details

and verify the back stack behaves as expected.

Test using:

3-button navigation
Gesture navigation

Predictive back behavior can differ from traditional button-based testing, so both should be tested.

Temporary Workaround

If your application is currently affected and you need to stabilize the release, one possible temporary configuration is:

<application
    ...
    android:enableOnBackInvokedCallback="false">

After rebuilding the application:

cd android
./gradlew clean
cd ..

Then rebuild:

npx react-native run-android

or use your normal release build process.

For an Expo bare/prebuild project, make sure the generated Android configuration is also correctly reflected in the source configuration you use for builds, rather than relying on a manual change that can be overwritten.

Recommended Migration Approach

Instead of treating the manifest flag as the final solution, I recommend approaching the migration in this order:

1. Upgrade target SDK → 36
          ↓
2. Test system Back
          ↓
3. Check React Native version
          ↓
4. Check React Navigation versions
          ↓
5. Search for custom Android back handling
          ↓
6. Search for BackHandler overrides
          ↓
7. Test predictive back
          ↓
8. Update incompatible dependencies
          ↓
9. Use manifest workaround if required
          ↓
10. Remove workaround after proper migration

This approach makes it easier to identify the actual compatibility problem.

Important Takeaway

Upgrading:

targetSdkVersion

is not always just a build configuration change.

A target SDK upgrade can activate or expose new Android platform behavior.

For Android 16 / API 36, back navigation and predictive back behavior are especially important areas to test.

If your React Native app suddenly starts closing when the Android system back button is pressed after moving to target SDK 36, don't immediately assume that your React Navigation stack is broken.

First determine whether:

Android
   ↓
Back Dispatcher
   ↓
React Native
   ↓
React Navigation

is working correctly.

The following configuration can serve as a temporary compatibility workaround:

android:enableOnBackInvokedCallback="false"

but the preferred long-term solution is to ensure that the React Native and navigation stack properly supports Android's modern back-navigation APIs.

Final Checklist

Before releasing a target SDK 36 build, verify:

[ ] Android system Back navigates correctly
[ ] Root screen exits correctly
[ ] Nested navigation works
[ ] Modals handle Back correctly
[ ] Bottom tabs behave correctly
[ ] Authentication screens behave correctly
[ ] Deep links create the expected back stack
[ ] Gesture navigation works
[ ] 3-button navigation works
[ ] Predictive back behavior has been tested
[ ] React Native version is compatible
[ ] React Navigation dependencies are compatible
[ ] Custom BackHandler logic has been reviewed
[ ] Native onBackPressed() implementations have been reviewed
[ ] OnBackInvokedDispatcher usage has been reviewed
[ ] Any temporary enableOnBackInvokedCallback workaround is documented

Conclusion

Android 16 introduces another step in the evolution of Android back navigation. For React Native applications, upgrading to target SDK 36 can expose problems where the system Back button no longer reaches the JavaScript navigation layer as expected.

If your app starts closing instead of navigating backward, investigate the new Android back-dispatching behavior before modifying your navigation stack.

A manifest-level workaround such as:

android:enableOnBackInvokedCallback="false"

may restore the previous behavior temporarily, but dependency compatibility and proper predictive-back support should be addressed as part of the complete migration.

Target SDK upgrades should always be followed by dedicated navigation regression testing—not just build and installation testing.

✍️ Written by Dainy Jose — React Native Mobile Application Developer with 3+ years of experience building cross-platform mobile apps using React Native (Expo, TypeScript, Redux).
Currently expanding backend knowledge through the MERN Stack (MongoDB, Express.js, React.js, Node.js) to create more efficient, full-stack mobile experiences.

Tech Stack: React Native · TypeScript · Redux · Expo · Firebase · Node.js · Express.js · MongoDB · REST API · JWT · Jest · Google Maps · Razorpay · PayU · Agile · SDLC · Git · Bitbucket · Jira

Connect with me:
Portfolio
LinkedIn
GitHub

Google Play’s 2027 app quality requirements

Mon, 14 Sep 2026 15:41:55 +0000

Google Play is introducing new requirements for memory usage, code optimization, and automatic login restoration when users change Android devices. Announced on August 26, 2026, the changes take effect in February and April 2027.

Memory requirements from February 2027

Play will assess dynamic memory usage, measured as anonymous RSS plus swap, and memory held by bitmaps. The thresholds vary by process state, with separate dynamic memory limits for apps and games across device RAM tiers. The Android vitals tables list the applicable limits.

For phones and tablets, Play uses P90 measurements and the last 28 days of data. Evaluation includes available data from Android 13 onward. These requirements therefore reach beyond apps running on Android 17. Measurement scope.

Android 17 also introduces limits enforced by the operating system. Excessive memory use can trigger additional compression work and eventually process termination. Teams should examine memory use across foreground, background, and cached states.

DEX optimization from February 2027

Qualifying uploads must meet a minimum of 25% coverage in each of three areas: optimization, shrinking, and obfuscation. The requirement applies to apps with more than 10 MB of DEX code and games with more than 50 MB. These are DEX code thresholds, not total download sizes. DEX requirements.

Google recommends R8, although another optimizer can meet the requirement. Review optimization settings and keep rules, then inspect the percentages reported for the actual bundle uploaded to Play Console.

Apps offering optional or mandatory login must support automatic restoration of the user’s authenticated state when they transfer to another Android device. Google calls this Zero-Tap Sign-In. Games are currently exempt. Migration requirement.

The requirement covers phones and tablets. Apps without accounts are unaffected, and guests should remain guests. Block Store integrations qualify only if they successfully restore login and are in production by September 30, 2026. Other exceptions and exemption criteria are detailed in the technical requirements.

The recommended implementation uses Restore Credentials through Credential Manager. It includes creating a restore key for an authenticated user, handling restoration with the app’s backend, and deleting the key on logout. Plan for both app and backend changes.

Checks to schedule now

Inspect Android vitals memory metrics by device RAM tier and process state, including behavior after leaving the app.
Review the uploaded release bundle’s DEX size and optimization results. Test critical flows after changing R8 rules.
Audit the device migration flow with the authentication team and test both device transfer and cloud restoration.

Google says apps that miss the requirements may face reduced store visibility and publishing capabilities. Further enforcement details are still to come. Check the official announcement and technical requirements when planning releases.

Building the LBH Protocol from Android/Termux: A Sovereign Edge Architecture

Sun, 13 Sep 2026 02:04:44 +0000

By Cristhiam Leonardo Hernández Quiñonez (CLHQ)
Founder – HormigasAIS | Sovereign edge computing ecosystem – San Miguel, El Salvador
github.com/Thrumanshow/HormigasAIS

1. The Problem: Depending on the Cloud to Validate What's Real

Most content-verification and edge-computing stacks today assume a baseline dependency: a cloud provider, a centralized API, or a third-party service sitting between your data and the claim that it's authentic. That dependency is convenient, but it's also a single point of failure and a single point of control.

The question I kept returning to while building HormigasAIS was simple: can a verification system be sovereign? Not "self-hosted on someone else's cloud," but genuinely independent — running on infrastructure you own, from a device as unconventional as a phone.

2. The Solution: A Node Architecture Built on Sealing, Not Trust

HormigasAIS approaches this with a node-based architecture rather than a service-based one. Three pieces anchor it:

LBH cryptographic sealing — content is sealed using SHA-256 + HMAC-SHA256, with signed verification that doesn't require calling out to a third party to confirm integrity.
barrera.js — an ethical/logical filter layer (informally, "decromatiza") that sits between raw input and the system's accepted state.
humano.js — a small symbolic module declaring the human-language layer of the project: HormigasAIS = {{lenguaje-humano}}. It's less a functional API and more a positioning statement embedded directly in code — a reminder that the system is meant to stay legible to a human reader, not just to a machine.

None of this requires a data center. The full development loop — writing, testing, sealing, deploying — happens from an Android device running Termux.

3. The Implementation: From a 404 to a Working Node

The most concrete proof point is small on purpose. The repository Thrumanshow/HormigasAIS started as a set of governance and symbolic files with no public-facing page — visiting its GitHub Pages URL returned a plain 404.

Getting it live took: enabling GitHub Pages from the main branch root, writing a minimal index.html, and documenting the repo properly — README.md, LICENSE (MIT), GOVERNANCE.md, STATUS.md, and MANIFIESTO.md.

The entire sequence — clone, edit, verify with curl, commit, push, confirm 200 — ran from Termux on a Samsung A16, no laptop involved.

4. The Ecosystem: What's Actually Public

To be precise about what's verifiable versus conceptual:

Live and checkable:

hormigasais.com — main site
api.hormigasais.com — Worker API
docs.hormigasais.com — documentation
blog.hormigasais.com — blog
The formal LBH specification is deposited on Zenodo: DOI 10.5281/zenodo.17767205

Governance:
The project operates under an explicit GOVERNANCE.md, which is worth flagging precisely because it's unusual for a solo project: it draws a hard line between forking/using the code (permitted under license) and any claim of official representation or node status (which requires explicit, written recognition from the maintainer of record). Forks are welcome. Authority isn't inherited by default.

Still experimental:
The broader multi-agent decision system and node-validation layer are active work — not yet at the same level of external verifiability as the sealing protocol or the published spec, and I want to be upfront about that distinction rather than blur it.

If you're building anything edge-first, protocol-level, or just skeptical of cloud dependency by default — I'd welcome the conversation.

Getting Started with Native Android: Kotlin & Jetpack Compose

Tue, 08 Sep 2026 04:14:28 +0000

Hey devs! For anyone looking to get into native mobile development, I put together a starter guide on building Android apps using Kotlin and Jetpack Compose.

Key takeaways:

Transitioning from traditional imperative UI to modern declarative composables

Managing UI state with remember and mutableStateOf

Quick design cycles using live previews in Android Studio

Read the full post on SunnyWriteUps! Are you currently using Jetpack Compose, KMP, or cross-platform frameworks for your mobile builds?

https://sunnyblog.apexmansunny.workers.dev/posts/get-started-with-kotlin/

How to Fix Expo Doctor Errors in Expo

Mon, 07 Sep 2026 11:14:51 +0000

If you work with Expo long enough, you will probably run into expo-doctor.

You run:

npx expo-doctor

and instead of everything being green, you get something like:

✖ Check Expo config
✖ Check dependencies
✖ Check package versions

Sometimes there is one problem.

Sometimes there are several.

And sometimes the output looks much worse than the actual problem.

The good thing is that expo-doctor is usually pretty clear about what it does not like. The tricky part is knowing what the warnings actually mean and which ones you need to fix.

Here is how I usually work through Expo Doctor errors without immediately changing half of the project.

First, run Expo Doctor by itself

Start with:

npx expo-doctor

Let it finish and read the full output.

Do not immediately start changing dependencies just because you see a red ✖.

Expo Doctor runs several checks, and a failure in one check does not necessarily mean your entire project is broken.

For example, you might see:

✖ Check that packages match versions required by installed Expo SDK

That is very different from:

✖ Check for common project configuration problems

The first one points toward dependency versions.

The second could require looking at your Expo configuration.

So the first step is simply figuring out which check actually failed.

Check your Expo SDK version

A lot of Expo Doctor problems come down to package versions not matching the Expo SDK you are using.

You can check your Expo version in package.json:

{
  "dependencies": {
    "expo": "~54.0.0"
  }
}

The exact version will depend on your project.

You can also run:

npx expo --version

and:

npx expo config --type public

The important thing is to know which Expo SDK your project is actually using before changing dependencies.

This matters because Expo packages are not completely independent of the SDK.

You cannot always just install the newest version of every package and expect everything to work together.

Fix packages that are on the wrong version

One of the most common Expo Doctor messages is related to package versions.

For example:

✖ Check that packages match versions required by installed Expo SDK

Expo may tell you that some packages are expected to be on different versions.

If that happens, do not manually guess which version to install.

For Expo-managed projects, use:

npx expo install

Expo can use your current SDK to install compatible package versions.

You can also check the project with:

npx expo install --check

If it reports packages that are out of date, you can usually let Expo correct them with:

npx expo install --fix

This is generally safer than doing something like:

npm install package-name@latest

because the latest package version is not necessarily the version your current Expo SDK expects.

Do not blindly update everything

This is worth mentioning because it is an easy mistake to make.

Suppose Expo Doctor tells you that three packages have version mismatches.

You might think:

Fine, I'll just update everything.

Then you run something like:

npm update

and suddenly you have five new errors.

You have now changed many things at once, which makes it harder to figure out what actually caused the problem.

If Expo is telling you that a package should be on a specific version, start with that package.

For example:

npx expo install react-native-screens

rather than manually searching for the newest version and installing it.

Make one meaningful change at a time when possible.

It makes debugging much easier.

Check `package.json` for old dependencies

Another common situation is an old dependency that you no longer use.

Over time, a project can collect packages from old features, experiments, tutorials, or libraries you tried and later removed.

Your package.json might contain:

{
  "dependencies": {
    "some-old-package": "^1.2.3"
  }
}

even though nothing in your application imports it anymore.

If Expo Doctor complains about that package, first check whether you still need it.

Search your project for:

some-old-package

If there are no imports or references and you know you do not need it anymore, removing the dependency may be the correct fix.

For npm:

npm uninstall some-old-package

For Yarn:

yarn remove some-old-package

Then run Expo Doctor again.

Check for packages that are not compatible with your project

Sometimes the problem is not simply that a package is old.

A package may require native code or a setup that does not fit the way your Expo project is configured.

This becomes especially important when adding React Native libraries that were designed with bare React Native projects in mind.

You may install a package successfully with npm, but that does not automatically mean your Expo project is configured to use it correctly.

If Expo Doctor starts complaining immediately after adding a new library, that timing is useful information.

Try to remember:

What changed right before the error appeared?

If you just installed a package and Expo Doctor started failing, investigate that package first.

Check your Expo configuration

Expo Doctor can also complain about your project configuration.

Depending on your setup, this information may live in:

app.json

or:

app.config.js

or:

app.config.ts

For example, your configuration might contain something like:

{
  "expo": {
    "name": "My App",
    "slug": "my-app"
  }
}

If you recently changed your configuration, added a plugin, changed an Android or iOS setting, or installed a package that requires an Expo config plugin, check those changes carefully.

A configuration problem can sometimes look like a dependency problem because several parts of the Expo toolchain depend on the same project configuration.

Check Expo config plugins

Config plugins are another area that can cause confusion.

If you have something like:

{
  "expo": {
    "plugins": [
      "some-package"
    ]
  }
}

make sure that package is actually installed and that the plugin is valid for your current setup.

A common situation is:

You install a package.
You add its plugin to the Expo configuration.
Later, you remove the package.
The plugin entry stays behind.

Now Expo may still try to process something that no longer exists.

If you recently removed a native package, check app.json or your app config for leftover plugin entries.

Check for duplicate dependencies

Another useful thing to investigate is duplicate versions of the same package.

For example, your project might end up with different parts of the dependency tree using different versions of a React Native package.

You can inspect the dependency tree with npm:

npm ls

Or check a specific package:

npm ls react-native-screens

If you see multiple versions where you expected one, that can be a clue.

This does not automatically mean that multiple versions are wrong. Some projects legitimately have them.

The important part is to understand why they are there before trying to force everything onto one version.

Check your React Native version too

Expo SDK and React Native versions are closely related.

If you manually changed your React Native version, or upgraded one without properly upgrading the Expo SDK around it, Expo Doctor may start reporting compatibility problems.

For example, if your package.json contains:

{
  "dependencies": {
    "expo": "~54.0.0",
    "react-native": "..."
  }
}

make sure those versions belong together.

If you are upgrading Expo, follow the Expo upgrade process instead of manually changing a bunch of package versions and hoping they line up afterward.

A partially upgraded project is often harder to fix than a project that was left alone.

Run `expo-doctor` again after fixing something

This sounds obvious, but it is an important part of the process.

After making a change, run:

npx expo-doctor

again.

You want to know whether the change actually fixed the problem.

For example:

Before:
✖ Check package versions

After:
✔ Check package versions

Now you know that particular problem is gone.

If another check is still failing, you can work on that one separately.

This is much easier than making ten changes and running Expo Doctor once at the end.

What if Expo Doctor still fails?

If you have corrected the obvious dependency and configuration problems but Expo Doctor is still reporting an error, look at the exact check that is failing.

For example:

✖ Check for common project configuration problems

is not enough information by itself.

Read the lines underneath it.

Expo Doctor normally provides additional information about what it found.

That information is much more useful than the ✖ itself.

Copy the complete section of the output, not just the first line.

Clear the cache if the project still behaves strangely

Clearing caches is not usually the first fix for an Expo Doctor warning.

Expo Doctor is checking your project configuration and dependencies, so a cache reset will not magically fix an incorrect package version.

However, if you have already fixed the reported problem and the project is still behaving as if the old state exists, clearing the Metro cache can help.

For Expo:

npx expo start -c

This is particularly useful after changing dependencies, imports, or other files that Metro may have cached.

Just keep in mind that clearing Metro's cache and fixing Expo Doctor are two different things.

When reinstalling `node_modules` makes sense

If your package configuration looks correct but your installation itself seems broken, reinstalling dependencies can be worth trying.

Delete:

node_modules

Then reinstall:

npm install

Afterward:

npx expo-doctor

And if necessary:

npx expo start -c

I would not delete your lockfile automatically.

Your package-lock.json or yarn.lock records the dependency versions that your project is using. Removing it can cause a completely new dependency tree to be installed, which may introduce more changes than you wanted.

If you specifically need to regenerate the lockfile, that is a different situation.

Be careful when upgrading an Expo project

If the reason for your Expo Doctor errors is that you are trying to move to a newer Expo SDK, do not treat it like a normal dependency update.

An Expo SDK upgrade can involve:

Expo packages
React Native
React
native dependencies
config plugins
Android configuration
iOS configuration
other packages tied to the SDK

If you upgrade only one or two pieces, you can end up with a project where everything is technically installed but the versions do not belong together.

If your goal is specifically to upgrade Expo, follow the upgrade process for the target SDK rather than trying to fix every warning individually.

A simple way to approach Expo Doctor

When I get an Expo Doctor error, I usually work through it in this order:

1. Run Expo Doctor

npx expo-doctor

2. Find the failed check

Do not worry about every line yet. Find the actual ✖ checks.

3. Read the details underneath

That is usually where the useful information is.

4. Check what changed recently

Did you:

install a package?
update Expo?
update React Native?
remove a package?
change app.json?
add a config plugin?
switch branches?

Recent changes are often the best clue.

5. Fix the smallest thing first

If a package version is wrong, fix that package.

If a plugin is left behind, remove it.

If a dependency is no longer needed, uninstall it.

6. Run Expo Doctor again

npx expo-doctor

Then see what remains.

This gives you a much cleaner debugging loop.

One example

Imagine you run:

npx expo-doctor

and get a dependency version warning.

You check package.json and notice that you manually installed a newer version of an Expo-related package a few days ago.

Instead of immediately reinstalling everything, you can try:

npx expo install

or, if Expo identifies the package as needing a correction:

npx expo install --fix

Then run:

npx expo-doctor

again.

If the check passes, you have your answer.

If it does not, you now have a smaller problem to investigate.

That is the part that makes debugging much easier: change something, test it, and use the new output to decide what to do next.

Final thoughts

Expo Doctor is there to help you find problems before they turn into much bigger issues.

The important thing is not to treat every warning as a reason to rebuild your entire project.

Start with the exact check that failed.

If it is a dependency problem, check the package versions.

If it is a configuration problem, check your Expo config.

If you recently installed or removed a package, investigate that change.

And if you are upgrading Expo, make sure you are upgrading the related dependencies together instead of manually mixing versions.

Most importantly, avoid making a dozen changes at once. When you do that, even if the error disappears, you have no idea which change actually fixed it.

If your Expo Doctor output is more complicated—especially when several checks fail at the same time—you can paste the full error into FixMyError and use it to break down what the output is actually telling you.

You can try it at https://www.fixmyerrorapp.com.

How to Fix “Unable to Resolve Module” Errors in React Native and Expo

Fri, 28 Aug 2026 13:36:15 +0000

How to Fix “Unable to Resolve Module” Errors in React Native and Expo

If you have been working with React Native or Expo for a while, there is a good chance you have seen an error that looks something like this:

Unable to resolve module ./components/Header from App.js

None of these files exist:
  * components/Header(.native|.ios|.android|.js|.jsx|.ts|.tsx)
  * components/Header/index(.native|.ios|.android|.js|.jsx|.ts|.tsx)

Or maybe:

Unable to resolve module react-native-safe-area-context from App.js

Or the error is buried somewhere inside a much larger Metro bundler log, making it harder to see what is actually wrong.

The annoying part about this error is that "Unable to resolve module" does not always mean the same thing.

Sometimes the file path is wrong. Sometimes the package was never installed. Sometimes it is installed, but your dependencies are in a bad state. And sometimes everything looks correct until you notice that one letter in a filename has the wrong capitalization.

I've run into all of these before.

So instead of randomly deleting node_modules and hoping for the best, here is how I usually work through this error.

First, read the exact module Metro cannot find

This sounds obvious, but the first line of the error usually tells you exactly what Metro is looking for.

For example:

Unable to resolve module ./components/Header from App.js

Metro is trying to find:

./components/Header

relative to:

App.js

That immediately gives you something to check.

Ask yourself:

Does that file actually exist?
Is the path correct?
Is the filename spelled correctly?
Are you importing it from the correct folder?

For example, imagine your project looks like this:

my-app/
├── App.js
└── components/
    └── Header.js

Then this import should work:

import Header from "./components/Header";

But this will not:

import Header from "./component/Header";

One missing s is enough to break the build.

When the error points to a local file, I usually start here before doing anything else.

Check the file name and capitalization

This one can be surprisingly annoying, especially if your app worked on one machine but suddenly fails during a build or after pushing the project somewhere else.

Imagine your file is named:

header.js

But your import says:

import Header from "./components/Header";

Depending on the operating system and environment, this can cause problems because:

header.js

and:

Header.js

are not always treated as the same file.

The same thing can happen with folders:

Components/

vs:

components/

If Metro says it cannot find a local module and the path looks correct at first glance, check every part of the path carefully.

I have lost more time than I would like to admit because of a single capital letter.

Make sure the package is actually installed

Sometimes the missing module is not one of your own files.

For example:

Unable to resolve module react-native-safe-area-context

In that case, check whether the package exists in your project.

You can look inside package.json and see whether it is listed under dependencies.

For an Expo project, it is usually better to install Expo-compatible packages with:

npx expo install react-native-safe-area-context

For a regular React Native project, you would normally use:

npm install react-native-safe-area-context

or:

yarn add react-native-safe-area-context

The exact command depends on your project, but the important part is this:

Do not assume a package is installed just because you used it in your code.

It is also possible that you copied code from another project, tutorial, or GitHub repository without installing all of the required dependencies.

Check if the package name is correct

Another simple but common problem is importing the wrong package name.

For example, you might write something like:

import Something from "react-native-something";

but the actual package name could be slightly different.

Before reinstalling everything, check:

The package name in your import.
The package name in package.json.
The package name from the package documentation.

One small typo can produce the same "Unable to resolve module" error as a completely missing dependency.

Reset the Metro cache

If the file or package exists and the import looks correct, the next thing I would try is clearing Metro's cache.

For Expo:

npx expo start -c

For React Native, you can try:

npx react-native start --reset-cache

Metro caches information to make development faster, but occasionally the cache gets in the way after things change.

For example, you might have:

renamed a file,
moved a folder,
installed a new package,
changed an import,
switched branches in Git.

If the project is still behaving like the old version exists, clearing the cache is a quick thing to try.

I would not start by deleting half the project, though. Resetting the cache is much less destructive.

Check your `node_modules`

Sometimes the dependency is listed in package.json, but something went wrong during installation.

This can happen after:

switching branches,
changing package versions,
interrupting an installation,
moving the project to another computer,
or getting dependency conflicts.

A common approach is to reinstall your dependencies.

First, remove node_modules.

Then run:

npm install

Or, if you use Yarn:

yarn install

After that, start the project again and clear Metro's cache.

For Expo, that could look like:

npx expo start -c

Try to use the same package manager consistently. If your project uses package-lock.json, randomly switching between npm, Yarn, and other package managers can create confusing dependency problems.

Check whether you are importing from the correct location

This is especially easy to miss after moving files around.

Imagine you originally had:

src/
├── screens/
│   └── HomeScreen.js
└── components/
    └── Header.js

Inside HomeScreen.js, you might import:

import Header from "../components/Header";

Then later, you move HomeScreen.js somewhere else:

src/
├── app/
│   └── screens/
│       └── HomeScreen.js
└── components/
    └── Header.js

The old import path may no longer be correct.

You would need to update it accordingly:

import Header from "../../components/Header";

When you see an "Unable to resolve module" error after reorganizing your project, check whether the import path still matches the new folder structure.

Be careful with relative paths

Relative imports can become difficult to read when your project grows.

You might end up with something like:

import Something from "../../../../components/Something";

At that point, it becomes much easier to accidentally use one ../ too many or too few.

If the error points to a long relative path, carefully trace it from the file where the import is written.

For example:

import Header from "../../../components/Header";

Do not just count the dots and slashes quickly. Actually check the location of the current file and follow the path step by step.

It is boring, but it is often faster than trying random fixes.

Check whether the package is compatible with Expo

This is more important if you are using Expo.

You may find a React Native package online, install it successfully, and then run into problems because the version does not match your Expo SDK or the package needs native setup that your project does not currently support.

When possible, use:

npx expo install package-name

instead of blindly installing the latest version with npm.

Expo can choose a version that is compatible with your current SDK.

You can also run:

npx expo-doctor

to check your project for dependency and configuration issues.

If Metro suddenly cannot resolve something after installing or updating a package, compatibility is worth checking.

Watch out for renamed or removed files

Another situation that can cause this error is when your code still imports something that no longer exists.

For example, you rename:

OldButton.js

to:

CustomButton.js

but somewhere in the project, you still have:

import OldButton from "./OldButton";

The error might not happen immediately if that file is not loaded until you visit a specific screen.

This is why I would search the project for the old filename.

Your editor's global search is useful here. Search for:

OldButton

and see whether any old imports are still left behind.

Check `index` files

Sometimes the missing module is actually caused by an index.js or index.ts file.

For example:

components/
├── Button/
│   ├── Button.js
│   └── index.js

You might import it like this:

import Button from "./components/Button";

That usually depends on Metro being able to resolve the folder's index file correctly.

If index.js was deleted, renamed, or contains a broken export, your import setup may stop working.

Check whether the folder contains the file Metro expects.

For example:

export { default } from "./Button";

Or:

export { Button } from "./Button";

The correct setup depends on whether you are using default or named exports.

The important part is to check the whole import chain, not just the first file.

Default exports and named exports are a different problem, but still worth checking

This usually causes a different error, but it can easily appear around the same time.

For example, this is a default export:

export default Header;

And it is imported like this:

import Header from "./Header";

A named export looks like this:

export const Header = () => {
  return null;
};

And it should be imported like this:

import { Header } from "./Header";

If you have already fixed the module resolution error but the app still fails afterward, this is one of the next things I would check.

Sometimes you fix one problem and Metro finally gets far enough to show you the next one.

That is just part of debugging.

Monorepos can make module resolution more complicated

If you are using a monorepo, workspaces, shared packages, or code outside the main app folder, Metro module resolution can become more complicated.

Your project might look something like this:

my-project/
├── apps/
│   └── mobile/
└── packages/
    └── shared/

Then the React Native or Expo app might need to import code from:

packages/shared

In these cases, a normal relative import may not be enough. Metro may need additional configuration to watch or resolve files outside the main project directory.

If you only started seeing the error after introducing a workspace or shared package, I would focus on your Metro configuration instead of repeatedly reinstalling dependencies.

Monorepo issues usually need a more specific fix because the correct setup depends heavily on how the project is structured.

If you use Expo Router, check your imports and project structure

Expo Router adds another layer to how files are organized.

For example, your routes may live inside:

app/

and you may have layouts, route groups, and nested folders.

If you recently moved or renamed route files, double-check your imports and references.

Also make sure the required Expo Router packages are correctly installed for your current Expo setup.

When something goes wrong inside a routing setup, the error message may make it look like a general Metro problem when the real issue is simply an incorrect import somewhere inside a route or layout.

Again, start with the exact module Metro says it cannot find.

Do not immediately delete everything

When developers hit a module resolution error, a common reaction is to do all of this at once:

Delete node_modules
Delete package-lock.json
Clear Metro
Clear npm cache
Reinstall everything
Restart the computer

Sometimes that works.

But it can also make debugging harder because now you have changed five different things and do not know what actually fixed the problem.

I would usually check the error in this order:

Read the exact missing module.
Check whether the file or package exists.
Check the spelling and capitalization.
Check the import path.
Check whether the dependency is installed.
Clear the Metro cache.
Reinstall dependencies if necessary.
Check Expo or React Native version compatibility.
Investigate Metro configuration for more complex project setups.

This is usually much faster than throwing random commands at the project.

A quick example

Imagine you get this error:

Unable to resolve module ./components/ProfileCard from App.js

You check your project and see:

components/
└── Profilecard.js

The problem is the capitalization.

Your import says:

import ProfileCard from "./components/ProfileCard";

But the actual file is:

Profilecard.js

Rename the file so it matches:

ProfileCard.js

Then restart Metro if necessary:

npx expo start -c

That is a simple example, but it shows why reading the exact error matters.

The error is not always asking you to reinstall your entire project. Sometimes Metro is simply telling you that it cannot find something because the path does not exactly match what exists on disk.

Final thoughts

"Unable to resolve module" errors can look more serious than they really are.

Most of the time, the problem comes down to one of these things:

A wrong import path
A missing package
A typo in the package name
A filename capitalization problem
A stale Metro cache
Broken or missing dependencies
A file that was moved or renamed
A more complex Metro configuration issue

The biggest thing I have learned is to start with the exact module Metro says it cannot find.

Do not start by reinstalling the entire project.

Check what Metro is looking for, where it is looking from, and whether that file or package actually exists. In many cases, the answer is much simpler than the size of the error message makes it seem.

If your error is much messier than this—especially if the missing module is buried inside a large Expo, Metro, dependency, or build error—you can also paste the full error into FixMyError and get help breaking down what is actually causing it.

Sometimes the hard part is not finding a fix. It is figuring out which part of a long error log actually matters.

Try it here: https://www.fixmyerrorapp.com

How to Fix EAS Build Failed Errors in Expo

Tue, 11 Aug 2026 11:46:41 +0000

There is a particular kind of Expo error that I think almost every developer eventually runs into.

You make a change to your project, run your usual build command:

eas build

and instead of getting a nice .apk or .aab at the end, you get:

Build failed

And that's it.

Well, not really.

If you open the build logs, you get several hundred lines of output containing Gradle tasks, Android dependencies, warnings, stack traces, environment information, and somewhere in the middle of all of that is the actual reason your build failed.

I've been there more times than I'd like to admit.

The frustrating part is that "EAS Build failed" isn't really an error by itself. EAS is just telling you that something went wrong during the build. The actual problem can be a completely different issue.

It might be an Android dependency conflict.

It might be a missing environment variable.

It might be an invalid app.json configuration.

It might be a native package that doesn't work with your current Expo SDK.

Or it might be something as simple as a credentials problem.

So instead of trying random fixes, let's go through how I approach these failures and how to find the actual cause.

First: Don't Focus on "EAS Build Failed"

When you see:

Build failed

it's tempting to search for that exact phrase.

The problem is that thousands of completely different problems can end with the same message.

EAS Build is responsible for building your application. It isn't necessarily responsible for the thing that broke.

For example, your log might eventually contain:

Execution failed for task ':app:mergeDexDebug'

That's an Android dependency/build problem.

Or:

Could not resolve all files for configuration

That's pointing toward dependency resolution.

Or you might see something related to:

Missing environment variable

That's an environment/configuration problem.

And if you see something related to signing credentials, you're dealing with an entirely different category of failure.

The first thing I do is therefore ignore the generic "Build failed" message and find the first meaningful error underneath it.

1. Open the Full EAS Build Logs

Start by looking at the failed build in the EAS dashboard.

You can also list recent builds from your terminal:

eas build:list

Find the failed build and open its logs.

Don't just look at the last few lines.

The last line might say:

Build failed

but that doesn't tell you much.

Instead, search through the logs for terms such as:

ERROR
FAILURE
Error:
Caused by:
Exception
Could not
Unable to

The useful error is often somewhere above the final failure message.

For example, imagine the bottom of your log looks like this:

> Task :app:mergeDexRelease FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':app:mergeDexRelease'.

> com.android.builder.dexing.DexArchiveMergerException:
  Error while merging dex archives

BUILD FAILED

Build failed

The useful information isn't really:

Build failed

It's:

Execution failed for task ':app:mergeDexRelease'

and whatever caused the DEX merge to fail.

That distinction saves a lot of time.

2. Check Whether the Problem Is Actually Your Expo Configuration

One of the first things I check after an EAS build fails is the project's configuration.

Depending on your setup, this can include:

app.json
app.config.js
app.config.ts
eas.json

A small configuration mistake can prevent the native project from being built correctly.

For example, if you've recently changed:

{
  "android": {
    "package": "com.example.myapp"
  }
}

or added a plugin:

{
  "plugins": [
    "some-native-package"
  ]
}

and the build immediately started failing, that change is worth investigating.

The same applies to permissions, native configuration, app identifiers, and Expo config plugins.

If the failure started immediately after a configuration change, don't assume the EAS service itself is broken.

Look at what changed in your project first.

3. Check Your Expo SDK and Native Dependencies

This is one of the biggest sources of trouble I've encountered with Expo projects.

Expo SDK versions are tied to specific versions of React Native and a collection of native dependencies.

You can have a perfectly valid JavaScript project and still break the native build by installing a package that doesn't fit your current environment.

For example:

npm install some-package

looks harmless.

But if that package contains native Android or iOS code, it becomes part of your native build.

That's where things can get interesting.

Before randomly upgrading packages, check your project:

npx expo-doctor

This can identify common dependency and configuration problems.

If you're using Expo, I also recommend using Expo's package installation command when appropriate:

npx expo install package-name

rather than blindly installing a version with npm.

Expo can select a version that is compatible with your current SDK.

4. If the Error Mentions Gradle, Investigate the Android Build

Sometimes an EAS failure is actually an Android build failure hiding underneath Expo.

For example:

Execution failed for task ':app:mergeDexRelease'

or:

Could not resolve all files for configuration

or:

Duplicate class found

These are not really "Expo errors."

They're Android/Gradle dependency problems occurring during your Expo build.

This distinction matters because searching for:

EAS Build failed

will give you a huge number of unrelated results.

Searching for:

Execution failed for task mergeDexRelease React Native

is much more useful.

That's generally how I approach these logs: follow the most specific error rather than the generic EAS failure.

5. Check Your Environment Variables

Another surprisingly common cause of failed builds is an environment variable that exists locally but doesn't exist in EAS.

For example, your application might expect:

API_URL
SUPABASE_URL
SUPABASE_ANON_KEY

Your local development environment works because those variables exist in your .env file.

Then you create an EAS build and suddenly something breaks.

Why?

Because the remote build environment doesn't automatically have every variable from your local machine.

Check your EAS environment configuration:

eas env:list

Make sure the variables your application actually needs are available in the environment being used for the build.

This is especially important if the failure happens only on EAS while:

npx expo start

works perfectly locally.

6. Check Your EAS Build Profile

Your eas.json determines how your builds are configured.

A typical configuration might look something like:

{
  "build": {
    "development": {
      "developmentClient": true,
      "distribution": "internal"
    },
    "preview": {
      "distribution": "internal"
    },
    "production": {}
  }
}

If the problem only happens with one profile, compare that profile with the one that works.

For example:

eas build --profile preview

might work while:

eas build --profile production

fails.

That immediately gives you another clue.

The problem may not be your entire project. It may be something specific to the build profile.

7. Don't Ignore Credentials Errors

If the log mentions things such as:

credentials
keystore
provisioning profile
certificate
signing

don't start changing Gradle dependencies.

You're probably dealing with app signing or build credentials instead.

For Android, EAS can manage your app signing credentials for you.

You can inspect the credentials with:

eas credentials

If the error is specifically about signing, work through the credential configuration rather than treating it like a code or dependency problem.

This is one of those situations where identifying the category of the error is much more useful than knowing a particular command.

8. If It Worked Before, Ask What Changed

This is probably my favorite debugging question:

What changed immediately before the build started failing?

Don't underestimate how useful this is.

If yesterday you had:

EAS build → SUCCESS

and today you have:

EAS build → FAILED

something changed.

Maybe you:

installed a package
upgraded Expo
changed app.json
changed eas.json
modified environment variables
changed an Android dependency
added a config plugin
changed native code

Start there.

For example, if the failure appeared immediately after:

npx expo install some-package

I would investigate that package before touching ten unrelated parts of the project.

9. Clean Up Before Rebuilding

If you've already made changes trying to fix the problem, make sure you're not debugging an old local state.

For a native project, a clean build can sometimes help:

cd android
./gradlew clean
cd ..

For Expo projects using prebuild, you may also need to regenerate native projects depending on your setup.

But don't use cleaning as your first response to every error.

If the build is failing because a dependency is genuinely incompatible, cleaning won't magically make the dependency compatible.

It only removes cached/generated build artifacts.

The Most Important Part: Find the Root Error

This is the part that took me the longest to appreciate.

When a build log contains hundreds of lines, the error at the bottom isn't necessarily the error you need to fix.

For example:

Task :app:assembleRelease FAILED

is not particularly useful.

Neither is:

Build failed

The useful part might be 30, 50, or even 200 lines above it.

You might eventually find:

Duplicate class androidx.lifecycle.ViewModel

And suddenly the whole situation makes sense.

Or:

Could not resolve com.google.firebase:...

Now you're dealing with a dependency resolution problem.

Or:

Missing environment variable: API_URL

Now you know exactly where to look.

The final error tells you that the build stopped. The underlying error tells you why.

What If Your Error Doesn't Match Any Of These?

This is where things get much more frustrating.

You can search the exact error message and find ten different Stack Overflow answers.

One says to upgrade Gradle.

Another says to delete node_modules.

Another says to run expo prebuild --clean.

Someone else says to downgrade React Native.

And suddenly you're changing five different things without knowing which one actually matters.

I've made that mistake myself.

The problem with large React Native and Expo build logs is that they often contain a lot of information but very little prioritization.

You don't necessarily need another list of 15 possible fixes.

You need to know:

Which part of this particular log is actually causing the failure?

That's also the problem I wanted to solve with FixMyError.

Instead of manually digging through a huge React Native or Expo error log and trying to decide which line matters, you can paste the log into FixMyError and get a focused diagnosis aimed at identifying the most likely cause and the first fix worth trying.

It's particularly useful when your error doesn't fit neatly into one of the common categories above and you're staring at a wall of Gradle, Expo, or native build output wondering where to even start.

You don't need to use it for every error. If the log clearly tells you what's wrong, fix it and move on.

But when the useful information is buried somewhere inside a massive build log, that's exactly when a diagnostic tool becomes useful.

A Simple Workflow I Use Now

When an Expo EAS build fails, I don't immediately start changing dependencies or upgrading packages.

I go through this:

1. Find the actual failure

Don't stop at:

Build failed

Find the underlying error.

2. Identify the category

Is it:

configuration?
dependency?
Android/Gradle?
iOS/Xcode?
environment variables?
credentials?
native module compatibility?

3. Ask what changed

What did you install, upgrade, or modify immediately before the failure?

4. Check the full log

Don't assume the last error line is the root cause.

5. Run the relevant diagnostic tools

For example:

npx expo-doctor

and inspect your EAS configuration and dependencies.

6. Change one thing at a time

Don't simultaneously upgrade Expo, downgrade Gradle, delete node_modules, regenerate native projects, and change your dependencies.

If the build starts working afterward, you won't know what actually fixed it.

7. If the log is still unclear, diagnose the log itself

That's where a tool like FixMyError can save time.

Final Thoughts

An EAS Build failed message can look like a single problem, but it really isn't.

EAS is just the environment where the failure becomes visible.

The actual cause might be hiding in:

Expo configuration
native dependencies
Gradle
Xcode
environment variables
credentials
config plugins
or a package that isn't compatible with your current SDK

The biggest improvement you can make to your debugging process is to stop treating:

Build failed

as the error.

Treat it as the symptom.

Then work backward until you find the first specific failure that actually explains what happened.

And if you're staring at a huge build log and can't tell which of the hundreds of lines actually matters, that's precisely the kind of situation where having something analyze the error for you can be useful.

Happy debugging.

How to Fix `Execution failed for task ':app:mergeDexDebug'` in React Native

Tue, 04 Aug 2026 12:27:52 +0000

You make a small change to your React Native project, install a new package, or upgrade a dependency. Everything looks fine until you try to build your Android app.

Then Gradle stops with something like:

Execution failed for task ':app:mergeDexDebug'.

> com.android.builder.dexing.DexArchiveMergerException:
Error while merging dex archives

Or maybe you see:

Cannot fit requested classes in a single dex file

or:

Duplicate class found

At first glance, this error feels confusing because it happens during the Android build process, not inside your JavaScript or React Native code.

Your components are fine. Your logic is fine.

The problem is usually somewhere inside your Android dependencies.

In this guide, we will go through what causes mergeDexDebug failures, how to identify the real problem, and the fixes that actually work.

What Does `mergeDexDebug` Actually Mean?

When you build a React Native Android app, your JavaScript code is not the only thing being packaged.

Your project also includes native Android dependencies from:

React Native modules
Expo packages
Firebase libraries
AndroidX libraries
Third-party native packages

During the Android build, Gradle converts these Java/Kotlin dependencies into DEX files that Android can run.

The mergeDexDebug task is the step where Android combines those generated DEX files together.

When this step fails, it usually means:

there are too many methods to fit into one DEX file
two dependencies contain the same classes
dependency versions are conflicting

Cause 1: Your App Has Too Many Methods (64K Limit)

One of the most common reasons for this error is Android's method limit.

A single DEX file can only contain around 65,536 methods.

If your project includes many libraries, you can eventually exceed this limit.

The error usually looks like:

Cannot fit requested classes in a single dex file

or:

The number of method references in a .dex file cannot exceed 64K

This happens frequently in projects using packages like:

Firebase
Google Play Services
Maps
Analytics libraries
Multiple native modules

Fix: Enable Multidex

Open:

android/app/build.gradle

Find:

defaultConfig {
}

Add:

defaultConfig {
    multiDexEnabled true
}

Then add the multidex dependency:

dependencies {
    implementation 'androidx.multidex:multidex:2.0.1'
}

After that, clean your build:

cd android
./gradlew clean
cd ..

Then rebuild your app.

Cause 2: Duplicate Classes Between Dependencies

Another common reason is dependency duplication.

You may see something like:

Duplicate class androidx.lifecycle.ViewModel found in modules:

androidx.lifecycle:lifecycle-viewmodel:2.8.2

and

androidx.lifecycle:lifecycle-viewmodel-ktx:2.6.1

This means two libraries are trying to include different versions of the same Android classes.

Gradle does not know which one should be used, so the build fails.

Fix: Align Dependency Versions

Check your Android dependencies.

You can inspect your dependency tree with:

cd android
./gradlew app:dependencies

Look for libraries that appear multiple times with different versions.

For example:

androidx.lifecycle:lifecycle-viewmodel:2.8.2

androidx.lifecycle:lifecycle-viewmodel:2.6.1

The solution is usually to make all related dependencies use the same version.

After updating dependencies, run:

./gradlew clean

and rebuild.

Cause 3: A Recently Installed Native Package Introduced Conflicts

Sometimes the problem appears right after installing a package.

For example:

npm install some-native-library

Everything works until the next Android build.

This happens because native packages are not only JavaScript code. They also add Android dependencies.

A new package can introduce:

conflicting AndroidX versions
outdated libraries
duplicate classes

If the error appeared immediately after installing something new, that package is the first thing I would investigate.

How To Find The Real Cause Faster

Instead of guessing, get more information from Gradle.

Run:

cd android
./gradlew app:assembleDebug --stacktrace

The important part is usually not the final error line.

The useful information is often several lines above it.

Look for:

duplicate class names
conflicting library versions
dependency names

The last line often only says:

Execution failed for task ':app:mergeDexDebug'

but the actual reason appears earlier.

Clean Your Android Build Cache

After changing dependencies, Gradle may still use old build files.

Run:

cd android
./gradlew clean
cd ..

For React Native CLI projects:

npx react-native run-android

For Expo projects:

npx expo run:android

A surprising number of build problems disappear after a proper clean rebuild.

Preventing Future `mergeDexDebug` Errors

A few habits can save a lot of debugging time:

Keep dependencies updated

Old native dependencies are a common source of Android build conflicts.

Avoid installing unnecessary packages

Every native package increases the complexity of your Android dependency tree.

Check changes after adding native libraries

If your build breaks immediately after installing a package, don't start changing random Gradle files.

First check what dependency that package introduced.

Understand the error before applying fixes

A mergeDexDebug failure is not one single problem.

It is a symptom.

The real cause could be:

too many methods
duplicate classes
incompatible versions
a broken native dependency

Finding the cause is usually faster than trying random fixes.

Need Help Diagnosing React Native Errors?

Sometimes build errors are frustrating because the important clue is buried inside hundreds of lines of Gradle output.

That is exactly why I built FixMyError — a tool designed around the real debugging process developers go through.

You can paste your React Native or Expo error log and get a focused diagnosis that explains what is likely causing the problem and what fix is worth trying first.

Instead of searching through dozens of similar Stack Overflow answers, you can start with a clearer direction.

You can check it out here:

FixMyError

React Native Android build errors can look intimidating, but once you understand where the failure happens, most mergeDexDebug problems become much easier to diagnose.

The key is not memorizing commands.

It is learning how to read what Gradle is actually telling you.

How to Fix "Duplicate class ... found in modules" in React Native & Expo

Thu, 23 Jul 2026 12:36:11 +0000

If you've been developing with React Native or Expo for a while, chances are you've had a project that suddenly refuses to build for what seems like no reason.

Maybe you installed a new package. Maybe you upgraded Expo. Maybe you only changed a single dependency. You confidently run your Android build, expecting it to compile like always...

Instead, Gradle greets you with something like this:

Execution failed for task ':app:checkDebugDuplicateClasses'.

Duplicate class androidx.lifecycle.ViewModelLazy found in modules lifecycle-viewmodel-2.8.2.aar and lifecycle-viewmodel-ktx-2.6.1.aar

Duplicate class com.google.android.gms.internal.measurement.zzab found in modules play-services-measurement-base-22.0.0.aar and play-services-measurement-impl-21.6.2.aar

Duplicate class ...

At first glance, the error looks straightforward: there are duplicate classes. Easy enough, right?

Not exactly.

In reality, this is one of those Android build errors that can send you down a rabbit hole of Gradle files, dependency trees and Stack Overflow threads, only to realize the real cause was something completely different.

Let's break down what's actually happening and, more importantly, how to fix it.

Why this error happens

Every Android library included in your project contains compiled Java or Kotlin classes.

When Gradle builds your application, it combines all of those libraries into a single APK or AAB.

If two different dependencies contain the exact same class, Gradle doesn't know which version should be packaged.

Instead of guessing, it stops the build with a Duplicate class error.

The difficult part is that the dependency causing the conflict usually isn't the one shown in the error.

Very often, it's another package pulling in an older or incompatible version behind the scenes.

The most common causes

After seeing this error many times, these are usually the culprits.

1. Two libraries depend on different versions of the same package

This is by far the most common scenario.

For example:

Library A requires:

androidx.lifecycle:lifecycle-viewmodel:2.8.2

while Library B depends on:

androidx.lifecycle:lifecycle-viewmodel:2.6.1

Both versions get added to your dependency graph, eventually leading to duplicate classes.

2. An outdated React Native package

Older React Native libraries often haven't been updated for newer AndroidX or Google Play Services versions.

Even though your project is current, that one dependency may still reference libraries released years ago.

3. Expo SDK upgrades

After upgrading Expo, many native dependency versions change.

If one third-party package hasn't caught up yet, Gradle may end up resolving incompatible versions.

This is especially common immediately after major SDK releases.

4. Mixing manual native configuration with Expo-managed dependencies

Sometimes developers manually add Android dependencies that Expo already manages internally.

The result is two copies of essentially the same library.

How to fix it

There isn't one universal solution, but these steps solve the majority of cases.

Step 1 — Read the duplicated class carefully

Don't focus on the entire error.

Look specifically for the two modules involved.

For example:

lifecycle-viewmodel-2.8.2

lifecycle-viewmodel-ktx-2.6.1

Those names usually point you toward the conflicting dependency.

Step 2 — Find who is importing it

Run:

./gradlew app:dependencies

./gradlew app:dependencyInsight --dependency lifecycle-viewmodel

This shows which package is pulling each version into your project.

It's much faster than guessing.

Step 3 — Update outdated packages

If one library is significantly behind, updating it often resolves the conflict immediately.

Always check whether a newer version exists before trying complicated Gradle workarounds.

Step 4 — Clean the project

Sometimes Gradle continues using cached artifacts.

Try:

cd android

./gradlew clean

Then rebuild.

Step 5 — Regenerate native files (Expo)

If you're using Expo Prebuild:

npx expo prebuild --clean

This recreates the native Android project using your current configuration.

Step 6 — Force dependency versions (only if necessary)

Sometimes you need to force Gradle to use one specific version.

For example:

configurations.all {
    resolutionStrategy {
        force "androidx.lifecycle:lifecycle-viewmodel:2.8.2"
    }
}

Use this carefully.

If two libraries genuinely require incompatible versions, forcing one version may create runtime problems later.

How to avoid this error in the future

While duplicate class errors can't always be prevented, these habits reduce the chances considerably.

Keep Expo SDKs reasonably up to date.
Avoid abandoned React Native libraries.
Update dependencies together instead of one at a time.
Review package compatibility before major upgrades.
Avoid manually adding Android dependencies unless absolutely necessary.

When the error isn't actually the problem

One thing that makes this error frustrating is that the duplicate classes are often just a symptom.

The real issue might be:

an outdated library,
conflicting Firebase dependencies,
mixed AndroidX versions,
incompatible Google Play Services packages,
or an incomplete Expo migration.

That's why simply searching the duplicated class name doesn't always lead to the correct fix.

Understanding why those dependencies ended up together is usually more important than the class itself.

How FixMyError can help

Instead of manually digging through Gradle output, dependency trees and dozens of forum posts, you can paste the full error into FixMyError.

The tool analyzes the build log, identifies the likely source of the conflict, explains what's happening in plain English, and suggests fixes based on the specific dependencies involved.

Rather than treating every duplicate class error as identical, it tries to narrow the problem down to the actual cause behind your particular build failure.

Final thoughts

Duplicate class errors are among the most frustrating Android build issues because the message rarely points directly to the package that's responsible.

The good news is that, in most cases, the problem comes down to dependency resolution rather than something fundamentally broken in your project.

Once you identify which libraries are introducing conflicting versions, the fix usually becomes much more straightforward.

If you're currently staring at a wall of Gradle output wondering where to begin, start by identifying the conflicting modules, trace where they're coming from, and work outward from there.

It takes a bit of patience, but it's almost always easier than blindly trying random fixes from different Stack Overflow threads.

How to Fix: "Namespace not specified" Gradle 8 Error in React Native & Expo

Thu, 09 Jul 2026 12:45:41 +0000

Fixing the "Namespace Not Specified" Error in React Native and Expo Android Builds

If you recently upgraded a project to React Native 0.73+ or bumped your Expo SDK to version 50+, you may have run into an Android build error that looks something like this:

FAILURE: Build failed with an exception.

* What went wrong:
A problem occurred configuring project ':react-native-some-old-library'.

> Namespace not specified for group 'react-native-some-old-library'
  and version '1.0.0' as per the Android Gradle Plugin 8.0+ guidelines.

At first glance, it looks like something is wrong with your app. In most cases, it isn't.

The error is usually coming from an older dependency inside node_modules.

Here's what's actually causing it and how to fix it properly.

The Root Cause

Before Android Gradle Plugin (AGP) 8.0, Android libraries could define their package name inside AndroidManifest.xml.

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.someoldlibrary">

Starting with AGP 8.0, that is no longer enough.

Every Android module is now expected to define a namespace inside its build.gradle file.

When you upgrade React Native or Expo, your Android tooling gets upgraded as well. The problem is that many older React Native libraries haven't been updated to follow the new requirement.

As soon as Gradle encounters one of those libraries, it stops during configuration and the build fails.

This started showing up much more frequently after Expo SDK 50 and newer React Native releases adopted newer Android tooling.

Before You Change Anything

Look closely at the error message.

Most of the time you'll see something like:

A problem occurred configuring project ':react-native-some-old-library'

That project name is usually the library causing the issue.

A common mistake is to start editing your app's own Gradle files. In most cases, the problem is actually inside the dependency listed in the error.

The Fix: Use patch-package

Since the problem comes from a third-party library, editing files directly inside node_modules isn't a real fix.

The next time you run npm install, your changes will be overwritten.

Instead, make the change once and save it using patch-package.

Step 1: Find the Package Name

Navigate to the library's manifest file:

node_modules/react-native-some-old-library/android/src/main/AndroidManifest.xml

Look for the package attribute:

<manifest
    package="com.someoldlibrary">

Copy that value.

You'll use it as the namespace in the next step.

Step 2: Add the Missing Namespace

Open:

node_modules/react-native-some-old-library/android/build.gradle

Find the android {} block and add the namespace at the top:

android {
    namespace "com.someoldlibrary"

    compileSdkVersion safeExtGet('compileSdkVersion', 34)

    defaultConfig {
        minSdkVersion safeExtGet('minSdkVersion', 21)
        targetSdkVersion safeExtGet('targetSdkVersion', 34)
    }

    // ...
}

Make sure the namespace exactly matches the package name from the manifest.

Step 3: Generate a Patch

From your project root, run:

npx patch-package react-native-some-old-library

This creates a file inside a new patches directory containing the modification you just made.

Commit that file to Git.

Step 4: Apply the Patch Automatically

Open package.json and add a postinstall script:

{
  "scripts": {
    "start": "expo start",
    "android": "expo run:android",
    "ios": "expo run:ios",
    "postinstall": "patch-package"
  }
}

Now whenever someone runs npm install—whether it's you, another developer, CI, or EAS Build—the patch gets applied automatically.

That's It

Clear any caches if needed and run your Android build again.

The build should now complete normally.

More importantly, you won't have to keep making the same edit every time node_modules gets reinstalled.

If you're working with older React Native dependencies, this is usually the cleanest way to handle AGP 8 namespace issues without waiting for the library maintainer to release an update.

How to Fix FCM "MismatchSenderId" in Multi-Environment Expo (EAS) Builds

Sat, 27 Jun 2026 09:03:38 +0000

How to Fix `MismatchSenderId` in Expo EAS Push Notifications Across Multiple Environments

If you are managing multiple environments (Staging, Preview, Production) in a React Native Expo app, setting up Firebase Cloud Messaging (FCM) can quickly turn into a credential nightmare.

You set up separate Firebase projects for each environment, download your config files, and configure your service accounts. Everything looks right. But when you test push notifications on your staging build, you hit a wall:

Error: MismatchSenderId

This error doesn't mean your code is broken. It means you've hit a structural limitation in how Expo EAS handles push credentials.

Here is exactly why this happens and how to architect a clean solution.

Why the Mismatch Happens

The MismatchSenderId error occurs because of a strict identity mismatch:

The device token was generated by Firebase Project A, but the notification payload was dispatched using credentials from Firebase Project B.

In a standard web or backend setup, this is easy to manage. But in the Expo ecosystem, you run into the EAS Project Limit:

Expo maps push notification service accounts per EAS Project, not per EAS Build Profile (development, preview, production).

When you run eas credentials or use the automated CLI prompts, EAS expects one default push notification Service Account (SA) key for the entire project.

If you try to reuse or attach the same service account across different Google Cloud/Firebase projects via IAM permissions, FCM will reject the cross-project token request, throwing MismatchSenderId.

Solution 1: Split Your EAS Projects (Recommended for Clean Automation)

If you want to rely on Expo's automated push notification infrastructure without overriding credentials constantly, the cleanest architectural fix is to separate your environments at the EAS project level.

Instead of one EAS project with multiple build profiles, initialize separate EAS projects in your ecosystem:

your-app-staging
your-app-production

Implementation Steps

In your app.json, dynamically switch the expo.projectId and expo.slug based on an environment variable during your build step:

{
  "expo": {
    "name": "Your App",
    "slug": "your-app-production",
    "extra": {
      "eas": {
        "projectId": "YOUR-PROD-PROJECT-ID"
      }
    }
  }
}

Link your staging build profile to your staging EAS project.

Run eas credentials for each project separately. This allows you to upload the staging FCM Service Account to your staging EAS project, and the production FCM Service Account to your production EAS project.

Solution 2: Bypass EAS and Route Tokens on Your Backend

If separating your EAS projects isn't an option and you need to keep everything under a single Expo App ID, you have to stop relying on Expo's unified push notification server and handle routing downstream.

Implementation Steps

Tag Tokens by Environment

When your app requests a push notification token using Expo.getExpoPushTokenAsync(), append the current build environment metadata before sending it to your database:

const token = await Expo.getExpoPushTokenAsync();

// Save to backend alongside the environment flag
await saveTokenToBackend({
  token: token.data,
  environment: process.env.EXPO_PUBLIC_APP_ENV // 'staging' or 'production'
});

Handle Routing on Your Server

On your backend infrastructure, do not use a single global Firebase initialization instance.

Initialize multiple Firebase Admin SDK instances using the respective service account JSON keys for each environment.

When triggering a notification, check the token's environment tag and dispatch it explicitly through the matching Firebase Admin instance.

Verification Checklist Before Your Next Build

Before you trigger your next EAS build, double-check that your native configuration files aren't bleeding into each other:

Config Plugins: Ensure your app.json or app.config.js uses a dynamic config plugin to load google-services.json (Android) and GoogleService-Info.plist (iOS) based on the target build profile. If your staging build accidentally bundles the production google-services.json, your token identities will instantly mismatch.
Sender IDs: Verify that the sender ID inside your bundled client-side Firebase config explicitly matches the project ID of the service account used by your notification server.

I actually built a quick web tool called Fix My Error to automate troubleshooting these kinds of React Native, Expo, and Gradle build traps. If you're stuck on a cryptic error log, feel free to drop it in there to grab the configuration fix.

How to Fix Expo's Cryptic Upgrade Trap: Android Resource Linking Failed (splashscreen_logo not found

Sat, 20 Jun 2026 12:10:50 +0000

How to Fix "resource drawable/splashscreen_logo not found" After an Expo SDK Upgrade

Upgrading your Expo SDK version to keep up with the latest App Store and Google Play requirements is usually a smooth process—until Gradle decides to punch you in the face with a cryptic asset compilation error.

If you just kicked off an Android build or ran a prebuild, and your terminal suddenly spit out a wall of red text looking exactly like this, you are not alone:

A failure occurred while executing com.android.build.gradle.internal.res.LinkApplicationAndroidResourcesTask$TaskAction
> Android resource linking failed
error: resource drawable/splashscreen_logo (aka com.yourcompany.app:drawable/splashscreen_logo) not found.

The worst part about this error is that it doesn't give you a file name, a line number, or any mention of Expo.

It just drops a native Android resource compilation failure and leaves you to figure out the rest.

Let's break down exactly why this happens during Expo upgrades and how to fix it in two minutes flat.

Why This Happens: The Missing Asset Trap

This issue is a classic side effect of how newer Expo SDK versions handle Continuous Native Generation (CNG) via the expo-splash-screen plugin.

In older versions of Expo, if you only wanted a solid background color for your splash screen, you could get away with just defining backgroundColor in your config and skipping the logo image entirely.

The native generator would handle it gracefully.

However, in newer Expo SDK configurations, the prebuild engine has become much more strict.

If the image property is missing from your splash screen configuration, the Expo generator completely skips creating the native Android XML drawable references for the logo.

When the Android Gradle plugin compiles the app layer, it looks into the generated styles for the splash screen layout, tries to link the splashscreen_logo asset, finds a blank void, and crashes the entire build.

How to Fix It

To resolve this, we need to explicitly force the Expo prebuild engine to map a valid drawable resource so Gradle stops complaining.

Step 1: Update Your App Configuration

Open your app.json (or app.config.js) file and locate your plugins array.

Make sure the expo-splash-screen plugin block contains both a background color and an explicit path to a fallback image asset.

Even if you don't actually want a logo on your splash screen, you need to provide a placeholder image (like a tiny 1x1 transparent or solid pixel matching your background color) to satisfy the native compiler.

"plugins": [
  [
    "expo-splash-screen",
    {
      "backgroundColor": "#ffffff",
      "image": "./assets/splash-icon.png"
    }
  ]
]

Step 2: Clear and Regenerate Native Directories

Because native Android build directories heavily cache old configurations, simply changing app.json isn't always enough to clear out the corrupted Gradle state.

Run the following commands in your terminal to wipe the slate clean and force a fresh native generation:

# If you are testing local native builds:
npx expo prebuild --clean

# Or if you are running a fresh release compilation:
npx expo run:android --variant release --no-build-cache

Once the prebuild engine re-runs with the new configuration, it will successfully generate the splashscreen_logo.xml drawable file inside your native directories, and Gradle will breeze right past the linking stage.

Interactive Reference & Live Fix

If you want to view a fully verified configuration block or run this code through an interactive debugger to make sure your syntax matches up perfectly, you can check out the public resolution ledger here:

Fix My Error

Final Thoughts

Native Android build failures often look terrifying because the error message points to generated resources rather than the actual configuration mistake.

In this case, the root cause is usually a missing splash screen image definition after upgrading to a newer Expo SDK version.

Once you add a valid image path and regenerate your native directories, the build should proceed normally.

Have you run into any other weird compilation errors while moving your project up to the latest Expo SDK?

Drop them in the comments below and let's unblock them.

Android 17 released

Wed, 17 Jun 2026 09:08:31 +0000

Google has released Android 17 and started rolling it out to most supported Pixel devices. The Android 17 source code is also available through AOSP, while new devices running the release are expected over the coming months.

Android 17 pushes the ecosystem toward adaptive layouts, Compose-first development, stronger privacy controls, stricter performance behavior, and new AI-facing app capabilities.

Adaptive-first becomes the default

The biggest practical change is around large screens. For apps targeting API 37, Android 17 removes the ability to opt out of orientation and resizability behavior on large screen devices. The system can ignore legacy restrictions such as screenOrientation, setRequestedOrientation(), resizeableActivity=false, and min or max aspect ratio constraints. Games remain exempt, but ordinary apps need to handle changing window sizes as a normal runtime condition.

That direction is reinforced by new multitasking features. Android 17 introduces App Bubbles for any app, a Bubble Bar on tablets and foldables, and interactive Picture-in-Picture for desktop-style environments. Apps that only look correct in a single portrait phone window will be under more pressure than before.

Activity recreation behavior is also changing. Android 17 no longer restarts activities by default for several common configuration changes that do not require a full UI redraw. Apps receive those updates through onConfigurationChanged(). Apps that depend on a full restart can opt in with android:recreateOnConfigChanges.

Android starts exposing app actions to AI agents

Google describes Android 17 as the beginning of a transition from an operating system to an intelligence system. The main developer-facing part of that shift is AppFunctions, a platform API with a Jetpack library that lets apps expose their own actions as callable tools for on-device agents.

In practice, this means an app can describe workflows such as creating a note, starting a task, or updating local data, then make those workflows discoverable to agent experiences. Gemini integration is still in private preview, but Google is already encouraging developers to identify the actions that make sense to expose.

Compose is now the forward path

Android development is now officially Compose-first. Google says new Android APIs, libraries, tools, and guidance will be built for Jetpack Compose. Legacy View components and View-based Jetpack libraries, including Fragments, RecyclerView, and ViewPager, are moving into maintenance mode with critical fixes only.

For existing apps, this does not mean rewriting everything immediately. It does mean that new UI work, adaptive navigation, multi-pane layouts, non-touch input support, and dynamic window handling will be much easier to align with the platform when built in Compose.

Performance rules get stricter

Android 17 introduces stricter app memory limits based on total device RAM. If a foreground app or service exceeds those limits, the system can terminate the process. Google is pairing this with tooling such as the R8 configuration analyzer, LeakCanary integration in Android Studio, ApplicationExitInfo diagnostics, and trigger-based profiling through ProfilingManager.

The platform also adds generational garbage collection improvements, a lock-free MessageQueue for apps targeting SDK 37 or higher, stricter handling for static final fields, and tighter custom notification view limits. Apps that depend on reflection into framework internals should be tested carefully.

Privacy and security changes to watch

Android 17 continues the move away from broad, permanent permissions. The release adds a system-level contact picker, customization options for the photo picker, a system-rendered location button for session-only precise location access, and an EyeDropper API for selecting a color from the display without broad screen capture access.

Local network access is also changing. Apps targeting Android 17 need either the ACCESS_LOCAL_NETWORK runtime permission or a system-mediated device picker for local network communication. SMS OTP protection is stronger as well, with Android delaying access to one-time-password messages in cases where apps are not the intended recipient or are targeting SDK 37 and above.

Other security updates include post-quantum cryptography support through secure hardware on supported devices, hybrid APK signing with v3.2, stricter native dynamic code loading, and safer password entry behavior for physical keyboards.

Media, camera, and accessibility updates

Android 17 adds several media and camera capabilities, including Eclipsa Video, RAW14 image support, vendor-defined camera extensions, an Extended HE-AAC software encoder, H.266 support paths, APIs for identifying camera device type, and constant-quality video recording controls.

Accessibility also gets attention through better Bluetooth LE Audio hearing aid support and more granular routing for notifications, ringtones, and alarms. CameraX and Media3 have been updated for Android 17, and Google notes that CameraX users should update to version 1.5.2 or 1.6.0+ to avoid a crash related to a newly added dynamic range mode.

Official announcement:
https://android-developers.googleblog.com/2026/06/Android-17.html

Android 17 developer site:
https://developer.android.com/about/versions/17

How to Fix "Module Could Not Be Found" in React Native & Expo

Tue, 16 Jun 2026 11:45:20 +0000

We’ve all been there.

You find an awesome library, you run npx expo install, you import it into your code, and you start your development server.

You expect magic.

Instead, your simulator turns blindingly red with an error that looks something like this:

ERROR Invariant Violation: TurboModuleRegistry.getEnforcing(...):
'RNGestureHandlerModule' could not be found.

Verify that your native modules are linked correctly.

Your app is completely bricked, your Metro bundler is acting confused, and you’re left wondering why a package you just installed is allegedly missing from the face of the earth.

Let's look at exactly why this happens and the 3-step checklist to clear it up without losing your sanity.

The Root Cause: JavaScript vs. Native Code

Modern Expo apps are beautifully split into two worlds:

The JS Bundle:

Your components, logic, and regular styles. Metro can hot-reload this in milliseconds.

The Native Layer:

The underlying Kotlin/Java and Swift/Objective-C code that actually talks to the phone's hardware.

When you install a package that uses native code (like react-native-gesture-handler, react-native-reanimated, or a map library), Metro cannot hot-reload native code into an active app binary.

If you are running a pre-built Development Client or using Expo Go, it only knows about the native modules that were compiled the last time you built the app.

It has no idea this new native module exists yet, so the registry panics and throws an Invariant Violation.

The Ultimate "Un-Brick My App" Checklist

Next time this red screen of death pops up, run through these three steps in order.

1. Rebuild the App Binary (The Absolute Must)

Simply restarting the Metro bundler won’t cut it.

You need to recompile your native code so the new library gets bundled into the actual simulator app.

Stop your server and run:

# For Android Simulators / Devices
npx expo run:android

# For iOS Simulators
npx expo run:ios

2. Force a Clean Prebuild (If Using Custom Native Directories)

If you are managing your own android or ios directories and things get desynced, force Expo to regenerate them with the new native dependencies linked:

npx expo prebuild --clean

This removes the generated native projects and recreates them from your Expo configuration, ensuring newly installed native packages are correctly integrated.

3. Nuke the Metro Cache

Sometimes Metro holds onto a stale dependency graph like a grudge.

If you’ve rebuilt the binary and it still complains, start your project while forcing a total cache clearance:

npx expo start -c

This clears Metro's cache and forces it to rebuild the dependency graph from scratch.

Final Thoughts

Native linking issues can feel incredibly frustrating because nothing appears wrong in your JavaScript code.

The problem is usually that your app binary and your JavaScript bundle have fallen out of sync.

Whenever you see errors like:

RNGestureHandlerModule could not be found
Native module cannot be null
TurboModuleRegistry.getEnforcing(...) failed
Module has not been registered

Run through this checklist:

Rebuild the app binary.
Run a clean prebuild if you're using native directories.
Clear the Metro cache.

Most of the time, one of those three steps will get you back up and running.

If you're reading this at 2:00 AM while violently copy-pasting cryptic mobile stack traces into search engines, I feel your pain deeply.

I got so tired of hunting down hidden Gradle errors and obscure CocoaPods issues that I decided to build a tool to automate the headache.

It's called Fix My Error.

I set up a completely registration-free sandbox right on the homepage using this exact native linkage error so you can see how it works in real time without handing over your data.

If you like how it parses the logs, you can drop your own daily errors into the core engine with a free account (which gives you 5 free fixes per day), or check out the Pro tier if you're working in a heavy production environment.

Give the sandbox a spin next time Expo decides to ruin your afternoon, and let me know if it helps your workflow.

How do you usually handle these types of native linking bugs?

Drop a comment if this checklist worked for you, or let me know if there's an obscure Expo error that's currently driving you crazy.

The React Native Native-Dependency Trap: How to Fix Demanding Build Failures Without Nuking node_mod

Tue, 09 Jun 2026 09:26:33 +0000

It’s the same story every time. You run a simple package upgrade, or you decide it's time to bump your Expo SDK version. Locally, JavaScript compiled perfectly. But the second you run a native build, your terminal explodes with hundreds of lines of red text.

On iOS, it’s a cryptic CocoaPods could not find compatible versions for pod or a sudden compilation failure in AppDelegate.mm. On Android, it’s a fatal Gradle lifecycle error or a missing namespace exception.

When native dependencies break, most developers fall back on the classic loop: delete node_modules, delete package-lock.json, clear cache, reinstall, and pray.

But blind-nuking your files rarely fixes the underlying architectural conflict. Here is how to actually diagnose and surgically resolve native dependency hell in modern React Native and Expo apps.

1. The Root Cause: Transitive Dependency Syncing

When you install a library like react-native-reanimated or a native camera module, that library relies on specific versions of underlying native libraries (Pods or Android libraries).

If two different third-party packages require the same native dependency but expect completely different versions, your package manager forces a compromise in JavaScript. But when the native build tool (Xcode or Gradle) steps in, it sees two conflicting native frameworks trying to occupy the same space.

For Expo Users: Always Prioritize the Pinned Versions

Running npm install can bypass Expo's guardrails. Always use:

npx expo install --fix

This forces Expo to look at your current SDK version and automatically downgrade or upgrade conflicting community packages to their exact validated native counterparts.

2. The iOS Podfile.lock Paradox

If your team introduces a package or you pull down main and suddenly iOS won't build, the culprit is usually an out-of-sync Podfile.lock. Running pod install blindly sometimes isn't enough if cached pods are conflicting.

The Surgical Fix

Instead of deleting your whole project configuration, clear the native iOS build cache specifically:

cd ios && pod cache clean --all
rm -rf Pods Podfile.lock
pod install

This forces CocoaPods to re-evaluate the dependency tree from absolute scratch based on your current package.json, without losing your local JS settings.

3. The Android Gradle Namespace Meltdown

With newer versions of Gradle and React Native, the way native Android modules declare their packages has changed (moving entirely to namespace inside build.gradle).

If you are using an older, unmaintained community package, Gradle will completely fail to compile the app on launch.

The Surgical Fix

Instead of waiting for an open-source maintainer to update a dead repository, you can use patch-package or Expo Config Plugins to alter the third-party library’s build.gradle file locally.

Alternatively, ensure your android/gradle.properties has the proper architecture properties enabled:

android.useAndroidX=true
android.enableJetifier=true

Triage Your Terminal Output

The biggest mistake developers make is trying to read the very bottom of a failed build log.

Xcode and Gradle put the actual error at the beginning of the failure block, while the bottom lines are just the generic system telling you the process exited with code 1.

Always scroll back up to locate the first root error flag.

I'm currently tracking down these weird native compilation bugs and building a database of exact solutions for them. If you are currently fighting a messy React Native or Expo native stack trace that makes absolutely no sense, I built a live beta engine to parse them and spit out precise resolutions over at fix-my-error-app.com. Drop your errors in there if you're stuck, and let me know in the comments what your most hated native build error is!

Drop your errors in there if you're stuck, and let me know in the comments what your most hated native build error is!

Lightbuild - a new declarative build experience for Android

Wed, 03 Jun 2026 13:38:12 +0000

Google has quietly published documentation for Lightbuild, a new build configuration experience for Android projects. Lightbuild is designed as a declarative, YAML-based build configuration layer for Android.

Today, Android projects usually use either Kotlin DSL or Groovy DSL for Gradle configuration. Google says Lightbuild will become a third option once it reaches general availability.

Instead of writing build logic directly, developers describe how the project should be built. Lightbuild then converts that declarative configuration into another build system, such as Gradle, which still performs the actual build behind the scenes.

Google describes Lightbuild as a build experience aimed at streamlining tasks in Android Studio and supporting agentic developer workflows through Android CLI.
The YAML format is a big part of that. Google says Lightbuild’s build files are designed to help AI agents parse build configuration, update dependencies, and edit modules more efficiently, while keeping those changes under developer control.

Google lists three main benefits:

Agent-friendly configuration - structured YAML should be easier for coding agents to read and safely edit.
Android CLI integration - Lightbuild is intended to work with the same Android CLI build and test features used by developers and agents.
Android Studio support - Lightbuild-based projects are designed to be fully supported inside Android Studio, including project templates and AI-created projects for users who have access.

For more info, check out the official post:
https://developer.android.com/tools/agents/lightbuild

How to Fix Gradle Error: Unsupported class file major version (React Native & Expo)

Wed, 03 Jun 2026 08:49:58 +0000

If your React Native or Expo Android compilation suddenly crashes with a massive terminal stack trace pointing to an "unsupported class file major version" or claims a class file has the wrong version (e.g., wrong version 65.0, should be 61.0), your environment is caught in a silent version mismatch.

This error almost always triggers right after you upgrade your Expo SDK, bump your React Native core version, or update Android Studio.

Here is exactly why this happens, how to decode the cryptic internal version numbers, and how to get your build compiling cleanly.

Why Did This Happen Suddenly?

When React Native or Expo upgrades their framework architecture, they also upgrade the required version of the Android Gradle Plugin (AGP) inside your project.

Each version of AGP requires a strict minimum version of the Java Development Kit (JDK) to run the compilation pipeline. If your system's global terminal runtime environment or your IDE is still pointing to an older Java runtime, the build engine throws an immediate exception during the semantic analysis phase.

The Version Decoder Cheat Sheet

Java’s compiler doesn't map version numbers logically to their public marketing names. When the Gradle stack trace throws a decimal number at you, use this index to figure out what version your code is demanding:

Class file major version 66.0 = Requires Java 22
Class file major version 65.0 = Requires Java 21 (Common in newer 2025/2026 native modules)
Class file major version 61.0 = Requires Java 17 (The baseline standard for modern React Native)
Class file major version 55.0 = Requires Java 11 (Legacy)

If your terminal says wrong version 65.0, should be 61.0, your build script encountered a dependency compiled for JDK 21, but your system is executing the build toolchain using JDK 17.

Step 1: Find the Exact Path to Your Target JDK

Before making adjustments, you need to locate where the correct JDK version is actually installed on your machine.

On macOS

If you use Homebrew or standard installers, your JDK runtimes are stored under the virtual machine path. You can list all installed environments by running:
/usr/libexec/java_home -V

Copy the path to the required version. It will look similar to this:
/Library/Java/JavaVirtualMachines/zulu-17.jdk/Contents/Home

On Windows

By default, standard Java installers or Android Studio bundle their JDK environments inside program directories. Check these common locations:

C:\Program Files\Java\jdk-17\
C:\Program Files\Android\Android Studio\jbr\ (Android Studio's embedded Java runtime)

Step 2: Apply the Explicit Project Override (Recommended)

Instead of fighting global system environment variables that might break older projects on your machine, you can force this specific React Native project to use the correct runtime directory.

Navigate to your project's native android folder: cd android
Open the gradle.properties file.
Add the following property at the bottom, supplying the absolute path you copied in Step 1:

org.gradle.java.home=/Insert/Your/Actual/Target/JDK/Path/Here

(Note: Windows users must escape backslashes in this file, format it like: C:\\Program Files\\Java\\jdk-17)

Step 3: Align Android Studio with Your Terminal

A massive source of frustration is when the project builds fine in the terminal via CLI, but crashes the second you open it in Android Studio (or vice versa). You must align the IDE's build path:

Open your project folder inside Android Studio.
Navigate to Settings (or Preferences on macOS) > Build, Execution, Deployment > Build Tools > Gradle.
Locate the Gradle JDK dropdown menu.
Change it from the default system runtime to match the exact version your project requires (e.g., JDK 17 or JDK 21).
Click Apply and hit Sync Project with Gradle Files.

Step 4: Clear the Aggressive Build Cache

Gradle caches compilation footprints deeply. If you change your Java version without clearing the cache, Gradle will try to read the old, mismatched class files and throw the same error again.

Wipe the execution deck completely by running these commands in your root directory:

Clean the native android directories

cd android
./gradlew clean

Return to root and clear bundler caches

cd ..
npx react-native start --clear

Once the development server reboots and paths match up seamlessly across your terminal, properties file, and IDE, run your run command (npx react-native run-android or npx expo run:android) and the version mismatch error will be gone.

Fixing Gradle TLS handshake_failure on Maven Central (Android Builds)

Tue, 02 Jun 2026 15:56:09 +0000

If your Android native build is constantly failing with a TLS handshake error when trying to download dependencies from Maven Central, the root cause might be an invisible environment variable polluting your Java settings.

The most frustrating part of this error is that your local internet connection is usually completely fine.

The Quick Diagnosis

Open your terminal and test the connection directly to the Maven repository using curl:

curl -I https://repo1.maven.org/maven2/

If curl connects successfully and returns an HTTP 200, but your Gradle build still throws a Received fatal alert: handshake_failure, your network is not the problem. Gradle itself is failing to establish the secure line.

The Root Cause

An environment variable called GRADLE_OPTS is likely injecting broken SSL or JSSE flags into your build process. Specifically, flags like -Djavax.net.ssl.trustStoreType=WINDOWS-ROOT force Gradle to look at system-specific certificate stores that conflict with standard Java behavior, breaking the handshake completely.

The Fix

To resolve this permanently, you need to wipe out the polluted configuration so Gradle can fall back to its clean JDK defaults.

Open your system Environment Variables settings.
Check both the User variables and the System/Machine variables.
Look for GRADLE_OPTS.
Delete the variable entirely from both locations.
Close your IDE, restart your terminal, and run your build again.

Once those injected flags are gone, Gradle will use standard JDK defaults, and your dependency downloads will start succeeding immediately.

I've been spending a lot of my spare time building out a diagnostic tool over at FixMyError to map out environment bugs like this automatically. I just put a live, free sandbox preview on the homepage if you want to see how the engine breaks down terminal stack traces before you ever make an account.

How to fix "Gradle build daemon disappeared unexpectedly" in React Native & Expo

Mon, 25 May 2026 10:18:22 +0000

If you’ve been building mobile apps with React Native or Expo long enough, you’ve definitely hit that brick wall where a standard debug build works perfectly, but the moment you run eas build or try to compile a production AAB/APK for the Play Store, the terminal throws a generic, frustrating crash:

"Gradle build daemon disappeared unexpectedly (it may have been killed or may have crashed)"

What makes this error so frustrating is that the terminal output rarely tells you why the daemon vanished.

The Root Cause: Out-of-Memory (OOM)

When you trigger a release build, the Node process responsible for bundling your JavaScript files, assets, and third-party native modules spikes heavily in memory. By default, Android's JVM (Java Virtual Machine) doesn't allocate enough heap space to handle these massive compilation steps for modern, dependency-heavy apps.

When the local or CI machine hits its limit, it forcefully kills the Gradle daemon to protect system stability.

The 3-Step Surgical Fix

Instead of blindly deleting your .gradle cache or reinstalling Android Studio, you can resolve this permanently by updating your configuration parameters.

1. Allocate More Heap Space

Navigate to your project's android/gradle.properties file and look for or append the org.gradle.jvmargs line. Increase the maximum heap size (-Xmx) to at least 4GB or 8GB depending on your app size:

org.gradle.daemon=true
org.gradle.jvmargs=-Xmx4g -XX:MaxPermSize=2048m -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8

2. Configure EAS Build (If using Expo)

If you are running your builds via Expo Application Services (EAS), you need to tell the remote builders to utilize a larger resource class. Open your eas.json file and specify a larger builder instance under your production profile:

{
  "build": {
    "production": {
      "android": {
        "resourceClass": "large"
      }
    }
  }
}

3. Clear and Reset

Once the files are saved, kill any lingering zombie daemons and clear the old build artifacts so Gradle can start fresh:

cd android
./gradlew clean
./gradlew cleanBuildCache

Taming the rest of your terminal logs

Native Android and iOS build logs can easily stretch to hundreds of lines of total noise, hiding the true dependency mismatch.

If you are currently fighting a different native module error or a breaking CocoaPods mismatch, I built a free developer utility called FixMyError that parses raw terminal dumps instantly. It strips out the conversational AI fluff and gives you the exact surgical terminal command or config change needed to unblock your build layout in 3 seconds.

Give it a spin if you are currently stuck: Try FixMyError Free

Let me know in the comments if increasing the JVM heap size successfully unblocked your production build!

Eunify: Bridging the Continuity Gap Between Mac and Android

Fri, 22 May 2026 17:24:01 +0000

If you’ve ever lived deep within the Apple ecosystem, you know the magic of Continuity. The ability to copy a link on your iPhone and instantly paste it on your Mac, or use your phone’s camera as a wireless webcam, feels like living in the future. Apple built these features seamlessly into their OS, giving their users a cohesive multi-device experience.

But what if you love your Mac, but prefer an Android phone? Out of the box, you get nothing. The wall around Apple's garden is tall, and cross-platform continuity has historically been clunky, relying on a patchwork of third-party apps that drain battery and feel decidedly un-magical.

Eunify (https://github.com/FredrickOdondi/eunify) changes that.

What is Eunify?
Eunify is an open-source "Continuity Bridge" designed specifically for users who split their digital lives between macOS and Android. It consists of a native macOS host app (built with Swift and SwiftUI) and an Android client (built with Flutter), tied together by a clever cloud relay system.

The goal? To give Android users the exact same seamless, real-time continuity features that were previously exclusive to the Apple ecosystem.

Bringing Apple Magic to Android
Eunify doesn't just mimic one or two features; it aims to replicate the entire Continuity suite:

Universal Clipboard: Copy text or a block of code on your Mac, and it instantly lands in your Android clipboard.
Tab & URL Push: Drag a Chrome or Safari tab onto the Eunify Mac app, and it opens instantly on your phone. You can also send links in reverse, from your Android back to your Mac browser.
Notification Mirroring: See your Android push notifications appear on your Mac in real-time, complete with actionable quick replies.
File Transfer: Drag any file onto the Mac app to send it directly to your Android device via high-speed P2P WebRTC.
Continuity Camera: Stream your Android phone's camera feed directly to your Mac to use as a wireless webcam.
Biometric Mac Unlock: Tap your fingerprint on your Android phone to unlock your Mac remotely.
Media Sync: See what's playing on your Android and control it right from your Mac desktop.
How It Works Under the Hood
Achieving this level of synergy across fundamentally different operating systems requires a robust technical foundation.

The Handshake: It starts with a simple QR code. The macOS app generates a QR code encoding a unique room ID. Scanning this with the Android app connects both devices to the same Supabase Realtime (WebSocket) channel.
Signaling: Standard events—like URL pushes, clipboard syncs, and notification mirroring—are securely transmitted as structured JSON payloads over the Supabase cloud relay.
Peer-to-Peer Streaming: For heavy lifting (binary data like files and live camera frames), the WebSocket channel is used to negotiate a direct WebRTC DataChannel. This ensures fast, secure, peer-to-peer data streaming without routing massive payloads through a cloud server.
Conquering Android Background Restrictions
One of the biggest hurdles for an app like this is keeping the connection alive while the mobile app is in the background. Modern Android is notoriously aggressive about killing background processes to save battery.

Eunify solves this with a two-layer approach:

A Foreground Service keeps the Supabase WebSocket connection alive with a WakeLock.
A separate Background Isolate written in Dart re-initializes the connection independently, handling message delivery even if the main UI is completely killed by the OS.
(It even employs clever workarounds, like using FlutterForegroundTask to briefly trampoline the app to the foreground on Android 10+ just to bypass background clipboard-writing restrictions.)

Get Started
If you're tired of emailing yourself links and want to bring your Android device into your Mac's ecosystem, Eunify is open source and ready to try.

Check out the code, read the full protocol design, and download the latest releases directly from the GitHub repository:

Explore Eunify on GitHub: https://github.com/FredrickOdondi/eunify

https://apkpure.com/eunify/com.eunify.client

Built with Swift, SwiftUI, Flutter, Dart, and Supabase.

Eunify: Cross-Platform Continuity System for Android and MacOS

Sun, 17 May 2026 22:12:01 +0000

I Was Just Solving a Problem that I Face as an Android Phone User
Working With MacOS. I Am Sure There's Someone Else Out There With
Similar Challenges

I developed Eunify, a continuity platform engineered to create a seamless, native-feeling ecosystem between macOS and Android. By bridging these two distinct operating systems, Eunify eliminates workflow friction and ensures uninterrupted cross-device synchronization for productivity and communication.

Core Features

Universal Clipboard: Instantly synchronize your clipboard across operating systems. Text or media copied on your macOS machine is immediately available to paste on your Android device.

Fluid Browser Handoff: Maintain uninterrupted browsing sessions across devices. You can drag and drop an active tab into Eunify on macOS to instantly launch it on your Android device, or push a tab from Android to pop up seamlessly on your Mac.

Bidirectional File Transfer: Securely and rapidly send files directly back and forth between your macOS and Android devices without relying on external cloud services.

Biometric Authentication Integration: Enhance your security workflow by leveraging your Android device's native biometric sensors to unlock your macOS laptop.

Video Call Continuity: Effortlessly hand off active video calls from your macOS machine to your Android device, allowing you to transition from your desk to mobile without dropping the connection.

5 React Native Errors That Cost Me Hours (And How I Finally Fixed Them)

Thu, 07 May 2026 19:35:56 +0000

5 React Native Errors That Cost Me Hours (And How I Finally Fixed Them)

When I started building my React Native app, I thought the hard part would be designing the app itself.

Turns out, debugging the environment was the real boss fight.

I spent hours — sometimes entire days — fighting build failures, version mismatches, Gradle issues, and errors that made absolutely no sense at first glance. Some of them looked impossible to solve unless you were already an Android engineer.

The worst part is that many tutorials online either skip these issues entirely or give solutions that don’t actually work.

So I decided to write the post I wish I had when I started.

These are 5 real React Native errors I personally ran into while building my app, and exactly how I fixed them.

1. Gradle TLS Handshake Failure

The Error

This one nearly made me quit for the day.

Every time I tried building the Android app, Gradle failed while downloading dependencies from Maven Central with SSL/TLS handshake errors.

The logs looked something like this:

javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure

Or sometimes:

Could not GET 'https://repo.maven.apache.org/...'

Why It Happened

At first I thought:

Maven Central was down
my internet was unstable
Java was broken
Gradle was corrupted

None of those were the real issue.

The actual problem was an environment variable called GRADLE_OPTS that was injecting custom SSL settings into Gradle.

It included flags like:

-Djavax.net.ssl.trustStoreType=WINDOWS-ROOT

Curl requests worked perfectly, but Gradle kept failing because its SSL configuration was being overridden.

How I Fixed It

I removed the GRADLE_OPTS environment variable completely from both:

User Environment Variables
System Environment Variables

Then I restarted the terminal and rebuilt the project.

Immediately after that, Gradle downloads started working again.

What I Learned

Sometimes the problem is not React Native itself.

Sometimes the environment around it is sabotaging the build process.

And when debugging network-related Gradle errors, always compare:

browser behavior
curl behavior
Gradle behavior

If only Gradle fails, something in the Java/Gradle SSL configuration is probably interfering.

2. Expo and React Native Version Mismatch

The Error

This one caused random crashes, dependency warnings, and builds failing for reasons that seemed unrelated.

I had packages that technically installed correctly, but internally they were incompatible with my Expo SDK version.

Why It Happened

React Native ecosystems are extremely version-sensitive.

You cannot always:

install the latest package
upgrade random dependencies
mix versions freely

Expo SDKs expect very specific versions of:

React Native
React
Expo packages
Gradle plugins
Android tooling

Even a small mismatch can create chaos.

How I Fixed It

I stopped manually installing random versions and aligned everything with the Expo SDK requirements.

I rebuilt the Android folder using the correct setup and standardized the project around:

React Native 0.80.2
Expo SDK 53
AGP 8.6.1
Kotlin 2.0.21
Gradle 8.13

After everything matched properly, the project became dramatically more stable.

What I Learned

In React Native development, version consistency matters more than having the newest package.

A stable stack beats a cutting-edge stack every single time.

3. Android Build Files Breaking Everything

The Error

At one point, Android builds completely stopped working because of Gradle configuration problems.

The project would either:

fail immediately
fail during dependency resolution
fail during configuration phase

And the logs were massive.

Why It Happened

React Native Android builds rely on multiple interconnected files:

settings.gradle
build.gradle
gradle.properties
app-level Gradle configs

One incorrect line can break the entire build system.

I also learned that newer React Native versions have different setup requirements compared to older tutorials online.

Following outdated tutorials made things worse.

How I Fixed It

I rebuilt the Android configuration using the proper modern structure:

correct includeBuild setup
Expo autolinking configuration
AndroidX enabled
Hermes enabled
New Architecture configuration aligned correctly

I also stopped randomly changing Gradle files without understanding what they did.

That alone saved me future debugging time.

What I Learned

When debugging Android builds:

avoid panic-editing files
change one thing at a time
keep backups of working configs

And most importantly:
older React Native tutorials can become outdated very quickly.

4. Metro Bundler Cache Weirdness

The Error

Sometimes the app behaved as if my code changes didn’t exist.

I would:

modify files
save changes
rebuild the app

…and somehow the old behavior remained.

At first I genuinely thought I was losing my mind.

Why It Happened

Metro bundler caching can occasionally become inconsistent, especially after:

dependency changes
package upgrades
Android rebuilds
native configuration updates

The cache can preserve outdated state even after rebuilding.

How I Fixed It

I cleared everything:

Metro cache
node_modules
Gradle cache
build folders

Commands like these became lifesavers:

npx expo start --clear

And sometimes:

gradlew clean

After cleaning the environment properly, the app started reflecting changes correctly again.

What I Learned

Never underestimate caching problems.

If behavior makes absolutely no sense, clear the caches before wasting hours debugging imaginary problems.

5. The “Works on One Device but Crashes on Another” Problem

The Error

This one was incredibly frustrating because the app seemed completely fine at first.

It worked on one device.
Then suddenly:

crashed on another device
failed on Android builds
behaved differently after rebuilding

Sometimes the exact same code would work one day and fail the next after changing dependencies.

Why It Happened

The real issue was inconsistency between:

Gradle versions
Android Gradle Plugin versions
Kotlin versions
React Native requirements
Expo SDK compatibility

At one point, parts of the Android environment were aligned while others were outdated or incompatible.

React Native Android builds are surprisingly sensitive to tooling mismatches.

Even if the app compiles, hidden incompatibilities can still create unstable behavior.

How I Fixed It

I standardized the entire Android stack instead of fixing things one-by-one.

I rebuilt the project around a stable configuration:

React Native 0.80.2
Expo SDK 53
AGP 8.6.1
Kotlin 2.0.21
Gradle 8.13
compileSdk 35
targetSdk 35

I also cleaned and regenerated parts of the Android setup to remove leftover configuration issues from older versions.

Once everything matched properly, the builds became dramatically more reliable.

What I Learned

A lot of React Native debugging problems are actually ecosystem consistency problems.

You can spend hours trying to patch symptoms individually when the real fix is making the entire toolchain compatible from top to bottom.

Now whenever I hit strange Android issues, the first thing I check is:
“Are all my versions actually meant to work together?”

Final Thoughts

Before building this app, I underestimated how much software development is actually debugging.

Not writing code.
Not designing features.

Debugging.

But strangely enough, this process also made me improve faster than any tutorial ever could.

Every painful issue forced me to:

understand the stack better
read logs more carefully
stay patient under frustration
stop blindly copying fixes from random forums

And honestly, solving these problems feels more rewarding than writing simple features.

If you're currently fighting React Native errors that make no sense:
you're definitely not alone.

Sometimes one line of configuration can cost you six hours.

And sometimes the fix is deleting a single environment variable.

We Built a Free, Fully Private Remote Control App for Windows. No Cloud, No Ads, No Compromise.

Wed, 22 Apr 2026 14:13:05 +0000

Most remote control apps make the same trade: convenience in exchange for your data passing through someone else's server.

We wanted to build something different. An app that gives you full control of your Windows computer from your Android device, without any of the mentioned privacy risks.

The result is RemotePC for Windows — a free, local network remote
control app with no ads, no data collection, and no cloud dependency
of any kind.

Why Local Network?

Cloud-based remote tools are useful, but they come with inherent trade offs: your input, your files, and your media commands all travel through an external server before reaching your own machine.

For a lot of use cases, especially at home or in a local office that round trip is completely unnecessary.

With RemotePC, your Android device and your Windows PC talk directly to each other over your local network. Your data never leaves it. There's no account to create, no server to trust, and nothing phoning home in the background.

What It Can Do

RemotePC covers the full range of remote control functionality you'd actually need day to day:

Trackpad & keyboard — Use your phone as a wireless trackpad and
keyboard for your PC
Media control — Play, pause, skip, and adjust volume without touching
your machine
Live statistics — Watch your computer's performance statistics. From
RAM and CPU usage, to temperatures RemotePC has it all
File transfer — Send files between your Android device and Windows PC
over the local network
And more — designed to handle the everyday remote control tasks most
users actually reach for

Completely Free. Actually Free.

There are no ads. There is no premium tier. There is no freemium gate hiding the useful features. RemotePC is free in the straightforward sense of the word.

Privacy by Architecture

RemotePC doesn't ask you to trust a privacy policy. The architecture itself is the guarantee — local network only means there's no external infrastructure that could collect, store, or transmit your data, because none exists. What happens on your network stays on your network.

Get It

RemotePC for Windows is available on the Google Play Store and UptoDown for Android.

Download it by visiting our web page here.

If you're looking for a lightweight, private, and genuinely free way to control your Windows PC from your phone — give it a try.

RemotePC by Breadworks.
Free and private — forever.

Build Reliable Local Notifications in Flutter (Step-by-Step)

Tue, 21 Apr 2026 01:03:01 +0000

Companion post to How I Built the Long Game Notification System. This is the walkthrough. If you want the thinking behind the decisions, read that first. If you just want the recipe, you're in the right place.

What You're Building

A notification system where:

Notifications fire at the exact time you set, every day
They work when the phone is locked, the app is killed, or the device is in Doze mode
Notification content is personalized with fresh data on every app open
The entire system runs locally — no push server, no Cloud Functions, zero delivery cost
Pomodoro-style one-shot alarms fire on time even when the app is suspended
Notifications survive Samsung, Xiaomi, and Huawei battery killers without FCM

What You're NOT Using

workmanager — the OS throttles background tasks. Your 15-minute poll becomes hours.
Dart Timer.periodic for delivery — dies the moment the phone locks.
Firebase Cloud Messaging — overkill for local, user-specific scheduling.
Background Fetch (iOS) — Apple gives you 0–2 executions per day if you're lucky.

Step 1: Dependencies

# pubspec.yaml
dependencies:
  flutter_local_notifications: ^18.0.1
  timezone: ^0.10.0
  flutter_timezone: ^3.0.1
  permission_handler: ^11.3.1

That's it. Four packages.

The notification plugin handles scheduling.
The timezone packages ensure your 8:00 AM means 8:00 AM in Johannesburg, not UTC.
The permission handler lets you request notification access on Android 13+ and battery optimization exemption on Samsung/OEM devices.

Step 2: Android Permissions

<!-- android/app/src/main/AndroidManifest.xml -->
<uses-permission android:name="android.permission.POST_NOTIFICATIONS" />
<uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED" />
<uses-permission android:name="android.permission.SCHEDULE_EXACT_ALARM" />
<uses-permission android:name="android.permission.USE_EXACT_ALARM" />
<uses-permission android:name="android.permission.REQUEST_IGNORE_BATTERY_OPTIMIZATIONS" />
<uses-permission android:name="android.permission.WAKE_LOCK" />

What each one does:

Permission	Why
`POST_NOTIFICATIONS`	Required on Android 13+ to show any notification at all
`RECEIVE_BOOT_COMPLETED`	Alarms survive device reboots
`SCHEDULE_EXACT_ALARM`	Fires at the exact second, even in Doze mode (API ≤ 33)
`USE_EXACT_ALARM`	Guaranteed exact alarms on API 33+ — no user prompt needed, unlike `SCHEDULE_EXACT_ALARM` on API 34+
`REQUEST_IGNORE_BATTERY_OPTIMIZATIONS`	Lets you show the system "Allow unrestricted battery?" dialog — critical for Samsung, Xiaomi, Huawei
`WAKE_LOCK`	Keeps the CPU alive long enough to process the alarm and fire the notification

Watch out: On Android 14+ (API 34), SCHEDULE_EXACT_ALARM isn't granted by default. USE_EXACT_ALARM is a stronger alternative that's always granted for apps that declare it — but it may trigger Google Play review. Having both ensures maximum compatibility. Your code still needs the inexact fallback we'll cover in Step 7.

Step 3: Initialize on App Start

Before you can schedule anything, you need to initialize the timezone database and the notification plugin. This runs once in main(), before runApp().

// main.dart
void main() async {
  WidgetsFlutterBinding.ensureInitialized();
  // ... your other init code (Firebase, etc.)

  await NotificationService.init();
  runApp(const MyApp());
}

// notification_service.dart
import 'package:flutter_local_notifications/flutter_local_notifications.dart';
import 'package:timezone/timezone.dart' as tz;
import 'package:timezone/data/latest_all.dart' as tzdata;
import 'package:flutter_timezone/flutter_timezone.dart';
import 'package:permission_handler/permission_handler.dart';

class NotificationService {
  static final FlutterLocalNotificationsPlugin _plugin =
      FlutterLocalNotificationsPlugin();

  static Future<void> init() async {
    // 1. Initialize the timezone database and detect the device's zone.
    //    Without this, all scheduled times are wrong.
    tzdata.initializeTimeZones();
    try {
      final tzName = await FlutterTimezone.getLocalTimezone();
      tz.setLocalLocation(tz.getLocation(tzName));
    } catch (_) {
      // Fallback: stays UTC if detection fails
    }

    // 2. Initialize the plugin.
    //    We don't request permissions here — that happens later,
    //    at a moment that makes sense in your UX flow.
    const androidSettings = AndroidInitializationSettings(
      '@mipmap/ic_launcher',
    );
    const iosSettings = DarwinInitializationSettings(
      requestAlertPermission: false,
      requestBadgePermission: false,
      requestSoundPermission: false,
    );

    await _plugin.initialize(
      const InitializationSettings(
        android: androidSettings,
        iOS: iosSettings,
      ),
      onDidReceiveNotificationResponse: _onNotificationTap,
      onDidReceiveBackgroundNotificationResponse: _onBackgroundTap,
    );
  }

  // Handle taps when the app is alive
  static void _onNotificationTap(NotificationResponse response) {
    // Navigate to the relevant screen, stop a timer, etc.
  }

  // Handle taps when the app was killed — must be top-level or static
  @pragma('vm:entry-point')
  static void _onBackgroundTap(NotificationResponse response) {
    // App relaunches — handle in your normal init flow
  }
}

Why timezone matters: If you schedule for "8:00 AM" without initializing timezones, the plugin may interpret that as UTC. In Johannesburg (UTC+2), that's 10:00 AM. In New York (UTC-5), that's 3:00 AM. Always initialize before any zonedSchedule call.

Step 4: Schedule a Daily Repeating Notification

This is the core of the entire system. Three lines do the heavy lifting.

static Future<void> scheduleDailyNotification({
  required int id,
  required String title,
  required String body,
  required int hour,
  required int minute,
}) async {
  await _plugin.zonedSchedule(
    id,                                           // Fixed ID per notification type
    title,
    body,
    _nextInstanceOfTime(hour, minute),            // Next occurrence of this time
    const NotificationDetails(
      android: AndroidNotificationDetails(
        'your_channel_id',
        'Your Channel Name',
        channelDescription: 'What this channel is for',
        importance: Importance.high,
        priority: Priority.high,
      ),
      iOS: DarwinNotificationDetails(),
    ),
    uiLocalNotificationDateInterpretation:
        UILocalNotificationDateInterpretation.absoluteTime,
    androidScheduleMode: AndroidScheduleMode.exactAllowWhileIdle,
    matchDateTimeComponents: DateTimeComponents.time,    // ← THIS IS THE KEY
  );
}

The three things that make it work:

exactAllowWhileIdle — fires even in Doze mode. The OS wakes up just enough to deliver your notification.
matchDateTimeComponents: DateTimeComponents.time — tells the OS: "repeat this every day at this hour:minute." You schedule it once. It fires every day. No background task. No polling.
_nextInstanceOfTime — computes the next future occurrence of the target time.

static tz.TZDateTime _nextInstanceOfTime(int hour, int minute) {
  final now = tz.TZDateTime.now(tz.local);
  var scheduled = tz.TZDateTime(
    tz.local,
    now.year,
    now.month,
    now.day,
    hour,
    minute,
  );
  // zonedSchedule requires a future datetime
  if (scheduled.isBefore(now)) {
    scheduled = scheduled.add(const Duration(days: 1));
  }
  return scheduled;
}

Why this helper exists: zonedSchedule requires the initial fire time to be in the future. If it's 9:00 AM and you schedule for 8:00 AM, the helper pushes it to 8:00 AM tomorrow. The matchDateTimeComponents flag handles every day after that.

Step 5: CRITICAL: The Cancel Trap

==(This bit is annoying if not taken care of)==

This is the bug that will silently break your notifications and you won't notice for days. I shipped it. It cost me a full day of missed notifications before I caught it.

The broken pattern

//  DO NOT DO THIS
static Future<void> reschedule() async {
  await _plugin.cancel(id);                     // Destroys the repeating alarm
  await _plugin.zonedSchedule(id, ...);         // Creates a new one
}

It looks correct. It's not. Here's what happens:

User opens the app at 9:00 AM
cancel(1) — destroys the existing repeating 8:00 AM alarm
_nextInstanceOfTime(8, 0) — 8:00 AM today already passed, returns tomorrow 8:00 AM
zonedSchedule(1, ...) — schedules a new alarm starting tomorrow
Tomorrow, user opens the app at 9:00 AM again → same thing
The notification is perpetually pushed to "tomorrow" and never fires

The correct pattern

// Only cancel when the user disables the notification
static Future<void> schedule(bool enabled, int hour, int minute) async {
  if (!enabled) {
    await _plugin.cancel(id);    // User turned it off — remove the alarm
    return;
  }
  // Calling zonedSchedule with the same ID REPLACES the existing alarm
  // without resetting the repeat cycle. No cancel needed.
  await _plugin.zonedSchedule(id, ...);
}

The rule: zonedSchedule with the same ID overwrites the previous alarm — it updates the title, body, and schedule time without destroying the repeat. You only need cancel when you want the notification to stop entirely.

This means you can safely call rescheduleAll() on every app open to refresh notification content (e.g., "You have 3 projects today" becomes "You have 4 projects today") without breaking delivery.

Step 6: Refresh Content on App Open

Notification bodies are frozen at schedule time. If the user adds a project at 11 PM, you want tomorrow's morning notification to include it.

// main.dart — after init, before runApp
if (FirebaseAuth.instance.currentUser != null) {
  NotificationService.rescheduleAllNotifications().catchError((_) {});
}

rescheduleAllNotifications() fetches fresh data and calls zonedSchedule for each enabled notification, overwriting the stale body. No cancel — just overwrite.

Two things to guard against:

Auth check — if your notification content depends on user-specific data (Firestore queries), and no user is signed in, the query will hang. This blocks main() and your app never starts. Gate it.
Fire-and-forget — use .catchError((_) {}). If the reschedule fails (offline, Firestore timeout), the previously scheduled alarm still fires with yesterday's content. That's better than crashing on startup.

Step 7: Handle Android 14+ Exact Alarm Restriction

Android 14 changed the rules. SCHEDULE_EXACT_ALARM is no longer auto-granted. If your app calls exactAllowWhileIdle without the permission, it throws.

The graceful fallback:

static Future<void> scheduleDailyNotification({
  required int id,
  required String title,
  required String body,
  required int hour,
  required int minute,
}) async {
  final scheduledTime = _nextInstanceOfTime(hour, minute);
  final details = /* your NotificationDetails */;

  try {
    // Try exact first — best experience
    await _plugin.zonedSchedule(
      id, title, body, scheduledTime, details,
      uiLocalNotificationDateInterpretation:
          UILocalNotificationDateInterpretation.absoluteTime,
      androidScheduleMode: AndroidScheduleMode.exactAllowWhileIdle,
      matchDateTimeComponents: DateTimeComponents.time,
    );
  } catch (e) {
    // Exact alarm not permitted — fall back to inexact
    // Delivery may drift by ~10 minutes, but the notification still fires
    await _plugin.zonedSchedule(
      id, title, body, scheduledTime, details,
      uiLocalNotificationDateInterpretation:
          UILocalNotificationDateInterpretation.absoluteTime,
      androidScheduleMode: AndroidScheduleMode.inexactAllowWhileIdle,
      matchDateTimeComponents: DateTimeComponents.time,
    );
  }
}

For most notifications, a 10-minute window is fine. "Your day is 63% gone" at 2:10 PM instead of 2:00 PM doesn't break the experience.

Apply this same pattern to one-shot alarms too. Your pomodoro alarm scheduler should have the same try/catch:

static Future<void> schedulePhaseAlarm({
  required int durationMinutes,
  required NotificationDetails details,
}) async {
  final fireAt = tz.TZDateTime.now(tz.local)
      .add(Duration(minutes: durationMinutes));

  try {
    await _plugin.zonedSchedule(
      alarmId, title, message, fireAt, details,
      uiLocalNotificationDateInterpretation:
          UILocalNotificationDateInterpretation.absoluteTime,
      androidScheduleMode: AndroidScheduleMode.exactAllowWhileIdle,
    );
  } catch (_) {
    // Fall back to inexact — still fires, may drift ~5-10 min
    try {
      await _plugin.zonedSchedule(
        alarmId, title, message, fireAt, details,
        uiLocalNotificationDateInterpretation:
            UILocalNotificationDateInterpretation.absoluteTime,
        androidScheduleMode: AndroidScheduleMode.inexactAllowWhileIdle,
      );
    } catch (e) {
      print('[Notifications] Failed to schedule alarm: $e');
    }
  }
}

Step 8: One-Shot Alarms (Pomodoro, Timers)

Daily repeating alarms cover most cases. But sometimes you need a notification that fires once at a specific future time — like when a 25-minute pomodoro focus session ends.

static Future<void> scheduleOneShot({
  required int id,
  required String title,
  required String body,
  required int minutesFromNow,
  required NotificationDetails details,
}) async {
  final fireAt = tz.TZDateTime.now(tz.local)
      .add(Duration(minutes: minutesFromNow));

  await _plugin.zonedSchedule(
    id,
    title,
    body,
    fireAt,
    details,
    uiLocalNotificationDateInterpretation:
        UILocalNotificationDateInterpretation.absoluteTime,
    androidScheduleMode: AndroidScheduleMode.exactAllowWhileIdle,
    // NO matchDateTimeComponents — this fires once, doesn't repeat
  );
}

Why you need this for pomodoro: A Dart Timer.periodic runs in your app's process. When the user locks their phone, the OS suspends the app within ~30 seconds. Your timer stops ticking. The phase ends, and — silence. The bell only rings when they unlock the phone and the app resumes.

An OS alarm doesn't care about your app's lifecycle. It fires regardless.

Making one-shot alarms alarm-grade

A standard Importance.high notification won't cut it on Samsung, Xiaomi, or Huawei devices. These OEMs aggressively kill background processes and suppress notifications they deem non-essential. You need to make your notification look like an alarm clock to the OS:

import 'dart:typed_data';

NotificationDetails _alarmGradeDetails({required bool isWorkPhase}) {
  final soundFile = isWorkPhase ? 'bell_focus' : 'bell_break';
  final channelId = isWorkPhase ? 'focus_bell' : 'break_bell';
  final channelName = isWorkPhase ? 'Focus Bell' : 'Break Bell';

  return NotificationDetails(
    android: AndroidNotificationDetails(
      channelId,
      channelName,
      channelDescription: 'Pomodoro phase transition',
      importance: Importance.max,                              // Maximum priority
      priority: Priority.max,
      sound: RawResourceAndroidNotificationSound(soundFile),
      playSound: true,
      fullScreenIntent: true,                                  // Wakes the screen
      category: AndroidNotificationCategory.alarm,             // Treated like an alarm
      visibility: NotificationVisibility.public,               // Shows on lock screen
      enableVibration: true,
      vibrationPattern: Int64List.fromList([0, 400, 200, 400]),
    ),
    iOS: DarwinNotificationDetails(
      presentAlert: true,
      presentSound: true,
      sound: '$soundFile.wav',
      interruptionLevel: InterruptionLevel.timeSensitive,      // Breaks through Focus
    ),
  );
}

What each flag does:

Flag	Effect
`importance: Importance.max`	Heads-up notification — appears at the top of the screen
`fullScreenIntent: true`	Wakes the screen and shows the notification even when locked. This is what alarm clock apps use.
`category: AndroidNotificationCategory.alarm`	Tells the OS this is time-critical. Samsung's battery manager respects this category.
`visibility: NotificationVisibility.public`	Content visible on the lock screen without unlocking
`vibrationPattern`	Custom vibration so the user physically feels it
`interruptionLevel: InterruptionLevel.timeSensitive`	iOS 15+: breaks through Focus mode

This is the difference between a notification that works on your desk and one that works in your pocket. Standard Importance.high gets silently suppressed by Samsung's battery manager. Importance.max + fullScreenIntent + category: alarm does not.

The dual-delivery pattern

When the app is in the foreground, the Dart timer catches the transition first (instant feedback). When the phone is locked, the OS alarm delivers it. To avoid the user hearing two bells:

// In your timer tick (foreground path)
void _onPomodoroPhaseEnd() {
  _plugin.cancel(alarmId);            // Cancel the OS alarm (Dart beat it)
  _plugin.show(displayId, ...);       // Show the notification immediately
  _scheduleNextPhaseAlarm();          // Schedule for the next phase
}

Use separate IDs for the scheduled alarm and the instant notification if you want, or the same ID if you want one to replace the other. Either way, the user sees exactly one notification.

Step 9: Weekly Repeating Notifications

For notifications that fire on specific weekdays — like a project reminder every Monday, Wednesday, and Friday at 6:00 PM.

static Future<void> scheduleWeekly({
  required int id,
  required String title,
  required String body,
  required int weekday,    // 1 = Monday, 7 = Sunday
  required int hour,
  required int minute,
}) async {
  await _plugin.zonedSchedule(
    id,
    title,
    body,
    _nextInstanceOfWeekdayTime(weekday, hour, minute),
    /* notificationDetails */,
    uiLocalNotificationDateInterpretation:
        UILocalNotificationDateInterpretation.absoluteTime,
    androidScheduleMode: AndroidScheduleMode.inexactAllowWhileIdle,
    matchDateTimeComponents: DateTimeComponents.dayOfWeekAndTime,  // ← Weekly
  );
}

static tz.TZDateTime _nextInstanceOfWeekdayTime(
  int weekday, int hour, int minute,
) {
  final now = tz.TZDateTime.now(tz.local);
  var scheduled = tz.TZDateTime(
    tz.local, now.year, now.month, now.day, hour, minute,
  );
  // Advance to the target weekday
  while (scheduled.weekday != weekday) {
    scheduled = scheduled.add(const Duration(days: 1));
  }
  // If it's already passed this week, push to next week
  if (scheduled.isBefore(now)) {
    scheduled = scheduled.add(const Duration(days: 7));
  }
  return scheduled;
}

Important: Each weekday needs its own notification ID. If you want reminders on Monday, Wednesday, and Friday, that's three separate zonedSchedule calls with three different IDs. When removing the reminder, cancel all of them.

// Generating unique IDs per project + weekday
final notifId = baseId + projectId.hashCode.abs() % 900 + weekday;

Step 10: Surviving Samsung Battery Optimization

This is the step most Flutter notification tutorials skip, and it's why your notifications work perfectly during development but fail silently in production.

The problem

Samsung, Xiaomi, Huawei, OnePlus, and most Chinese OEMs add an aggressive battery optimization layer on top of Android's standard Doze mode. Even if your alarm is correctly s

Why React Native Builds Break After Updating Dependencies (And How to Fix It)

Sun, 19 Apr 2026 16:39:23 +0000

Why React Native Builds Break After Updating Dependencies (And How to Fix It)

If you've ever updated your dependencies and suddenly your React Native Android build stops working… you're not alone.

Everything worked before.

You change a few versions, run the build again—and now you're hit with cryptic Gradle errors, build failures, or crashes.

This post breaks down why this happens and how to actually fix it.

The Real Problem

React Native projects depend on a fragile ecosystem of:

Gradle
Android Gradle Plugin (AGP)
Java (JDK)
Firebase / native SDKs
Third-party libraries

When you update even one dependency, you can accidentally break compatibility between them.

Common Symptoms After Updating

You might see errors like:

Execution failed for task ':app:compileDebugJavaWithJavac'
Duplicate class found in modules
Could not determine Java version
A problem occurred configuring project ':app'
App works before update, fails after

The problem is rarely obvious from the error message.

Why This Happens

1. Version Mismatch

Some libraries require:

Specific Gradle versions
Specific Android Gradle Plugin versions
Specific Java versions

If one gets upgraded and others don’t → build breaks.

2. Transitive Dependency Conflicts

When you install or update a package, it may bring its own dependencies.

Sometimes:

Two libraries depend on different versions of the same module
Gradle can't resolve the conflict → build failure

3. Cached / Corrupted Builds

Gradle caches aggressively.

After updates:

Old compiled artifacts remain
Build system gets inconsistent → weird errors

4. Breaking Changes in Libraries

Some updates introduce:

Removed APIs
Changed configurations
New requirements (e.g. minSdk, compileSdk)

How to Fix It (Step-by-Step)

1. Clean Everything

Run:

cd android
./gradlew clean

Then delete:

node_modules
android/.gradle
android/build

Reinstall:

npm install

2. Verify Java (JDK) Version

React Native (especially newer versions) typically requires:

JDK 17

Check:

java -version

Mismatch here breaks builds instantly.

3. Align Gradle + AGP Versions

Check:

android/build.gradle
gradle-wrapper.properties

Make sure:

Gradle version matches AGP requirements
You're not mixing incompatible versions

4. Check compileSdk / targetSdk

In android/app/build.gradle:

compileSdkVersion 34
targetSdkVersion 34

Some libraries require newer SDK versions.

5. Look for Duplicate Dependencies

If you see:

Duplicate class found in modules

You may need to:

Exclude dependencies
Align versions manually

6. Reset Environment Variables (Advanced but Important)

One issue I ran into:

A broken GRADLE_OPTS configuration caused TLS handshake failures and dependency download issues.

Fix:

Remove custom GRADLE_OPTS
Let Gradle use default JDK settings

This is rarely mentioned—but can completely break builds.

7. Rebuild from Scratch

Run:

npx react-native run-android

Key Insight

React Native builds don’t usually break randomly.

They break because: your environment and dependency versions are no longer aligned

Final Advice

When updating dependencies:

Don’t update everything at once
Upgrade incrementally
Test after each change

This makes debugging much easier.

If you're dealing with a specific error after an update, feel free to share it—I’ve probably hit it before

Android CLI

Fri, 17 Apr 2026 12:07:23 +0000

Google has announced Android CLI, a new official command line tool for Android development aimed at agent based workflows outside Android Studio. The release is part of a broader set of agent tools that also includes Android Skills and the Android Knowledge Base. Google says these tools are meant to help agents work with official Android workflows, recommended patterns, and up to date guidance.

According to the announcement, Android CLI is designed to handle core terminal based Android tasks such as environment setup, project creation, SDK management, emulator management, and app deployment. Google highlights commands such as android sdk install, android create, android emulator, android run, and android update as the foundation of the new workflow.

Google also says that in its internal experiments, Android CLI reduced LLM token usage for project and environment setup by more than 70 percent and completed tasks 3 times faster than agents using standard toolsets alone. That performance claim comes directly from Google’s own announcement, so it should be viewed as an internal benchmark rather than an independent measurement.

Google also launched the Android Knowledge Base. Google says it can be accessed through the android docs command and is intended to give agents fresher, authoritative context from Android developer docs, Firebase, Google Developers, and Kotlin documentation. That is an important detail for teams using coding agents, because it gives Android a more official path for grounding AI generated output in current platform guidance.

Official announcement:
https://android-developers.googleblog.com/2026/04/build-android-apps-3x-faster-using-any-agent.html

Understanding Flutter Method Channels Through a Real Production Bug

Thu, 16 Apr 2026 15:48:54 +0000

Introduction

Flutter is amazing—until it isn’t.

Most of the time, you can build entire apps without ever touching native code. But the moment you hit a platform limitation, things get… interesting.

This blog isn’t just about Method Channels.

It’s about:

When Flutter abstractions break down
How to take control using native Android
And how to think about Flutter ↔ Native communication like a system, not a hack

Funny enough, this blog comes from a real bug I hit while building my app Anahad — a saadhna app that plays mantra chants.

And yeah… it broke in a very weird way.

The Real Problem (Why This Blog Exists)

I was building a saadhna app that plays mantra chants on loop.

Simple requirement:

Play audio
Loop it continuously
Run in the background (screen off)

I was using:

audio_service
just_audio
just_audio_background

Everything worked perfectly…

Until it didn’t.

The Bug

After ~940–960 loops on Android (specifically Android 12+):

Playback would stop silently
No crash
No exception
Only when the screen was off

Even after:

Disabling battery optimization
Proper background setup

Still broke.

The Weird Part

It consistently failed around the same loop range (~940–960).

Not 100. Not 500. Not random.

That kind of consistency usually means:

Something deeper is going on — not just app-level logic.

At This Point, Two Choices

Keep debugging blindly inside Flutter
Drop down to native Android and take control

I chose option 2, cz i never interacted with native code and wanted to explore it

Fun part, i had an android 11 device which wasn't having this bug at all, tested on other android 11 devices as well

Why Flutter Isn’t Always Enough

Flutter is great, but it abstracts away platform details.

That’s usually good—until you need:

Deep lifecycle control
System-level integrations
Debug visibility into platform behavior

Common cases where native is needed:

Background services
Media playback control
Hardware interaction
Platform-specific APIs
Performance-critical logic

In my case:

I needed more control over how Android handles long-running audio playback. Just to be absolutely sure that it was not the issue of the package that i was using

Understanding Method Channels (The Right Mental Model)

Before code, get this clear:

Dart is the client. Native Android is the server.

When you write:

platform.invokeMethod("play")

You’re essentially doing:

Dart → sends request
Android → receives it
Executes native logic
Returns response

Think of it like:

An internal API call inside your app

No HTTP. No network. Just a binary bridge.

Once you understand this, Method Channels stop feeling “magical”.

Architecture Overview

Flutter (Dart)
├── UI Layer
├── Service Layer (PlaybackService.dart)
└── State Management

        ↓↓↓ Method Channel ↓↓↓

Android (Kotlin)
├── MethodChannel Handler
├── PlaybackService (MediaSessionService)
└── ExoPlayer

Flow (Step-by-Step)

User taps "Play"
Dart calls invokeMethod("play")
MethodChannel sends message
Kotlin receives it
Native service executes logic
Result is sent back

The Native Side: Android (Kotlin)

Why MediaSessionService?

Instead of a basic service, we use:

MediaSessionService

Because it:

Integrates with system controls (lock screen, notifications)
Handles background playback more reliably
Works with audio focus and lifecycle events
Plays nicely with the Android system

PlaybackService.kt

class PlaybackService : MediaSessionService() {
    private var mediaSession: MediaSession? = null

    override fun onCreate() {
        super.onCreate()

        val audioAttributes =
            AudioAttributes.Builder()
                .setUsage(C.USAGE_MEDIA)
                .setContentType(C.AUDIO_CONTENT_TYPE_MUSIC)
                .build()

        val player =
            ExoPlayer.Builder(this)
                .setAudioAttributes(audioAttributes, true)
                .setHandleAudioBecomingNoisy(true)
                .setWakeMode(C.WAKE_MODE_NETWORK)
                .build()

        player.addListener(object : Player.Listener {
            override fun onPlayerError(error: PlaybackException) {
                Log.e("PlaybackService", "Error: ${error.message}", error)
            }
        })

        val callback = object : MediaSession.Callback {}

        mediaSession = MediaSession.Builder(this, player)
            .setCallback(callback)
            .build()
    }

    override fun onDestroy() {
        mediaSession?.run {
            player.release()
            release()
            mediaSession = null
        }
        super.onDestroy()
    }
}

The Flutter Side: Dart

Service Wrapper

class PlaybackService {
  static const platform =
      MethodChannel('com.theahambrahmasmi.anahad/playback');

  static Future<void> play(String url) async {
    await platform.invokeMethod('play', {'url': url});
  }

  static Future<void> pause() async {
    await platform.invokeMethod('pause');
  }

  static Future<Map<String, dynamic>> getStatus() async {
    final result = await platform.invokeMethod('getStatus');
    return Map<String, dynamic>.from(result);
  }
}

Kotlin: Method Channel Handler

class PlaybackMethodHandler(private val context: Context) {

    fun setupChannel(flutterEngine: FlutterEngine) {
        MethodChannel(
            flutterEngine.dartExecutor.binaryMessenger,
            "com.theahambrahmasmi.anahad/playback"
        ).setMethodCallHandler { call, result ->

            when (call.method) {
                "play" -> {
                    val url = call.argument<String>("url")
                    val intent = Intent(context, PlaybackService::class.java)
                    intent.putExtra("audio_url", url)
                    context.startService(intent)
                    result.success(null)
                }

                "pause" -> {
                    val intent = Intent(context, PlaybackService::class.java)
                    context.stopService(intent)
                    result.success(null)
                }

                else -> result.notImplemented()
            }
        }
    }
}

Real-World Insight: The Looping Problem

If you're building:

Meditation apps
Chanting apps
Ambient loop apps

Be careful.

Android may silently stop long-running playback after extended loops.

Even with:

Battery optimization disabled
Background services configured

Test aggressively:

500+ loops
Screen-off playback
Different OEM devices

This is not just Flutter—it’s often Android system behavior.

What About The Root Cause?

Short answer:

I don’t fully know yet.

And yeah — that’s intentional honesty.

What I do know:

It only happens on Android 12+
It triggers after long-running background playback
It happens silently (no crash, no logs)
It correlates with a high loop count (~950)

Current Hypotheses:

Doze / background execution limits
Audio focus or media session interruption
ExoPlayer internal behavior after prolonged looping
OEM-level process killing
Resource exhaustion over time

We’ll Be Updating This

Once I dig deeper and find the exact root cause, I’ll update this blog with:

What exactly broke
Why Android 12+ behaves this way
The proper fix (not just experimental ones)
What you should do in production

Because honestly?

Debugging something that breaks at the OS level is messy… and kinda fun.

Final Thoughts

I eventually moved back to just_audio because:

The problematic flow was no longer needed

So yeah…

This experimental fix wasn’t used in production.

But it gave me something way more valuable:

A deeper understanding of how Flutter actually works under the hood.

And honestly?

I’m not perfect. I didn’t fully solve it (yet).
But now I know one more thing than I did before.

And that’s what matters.

TL;DR

Flutter is great, but not enough for everything
Method Channels = internal RPC bridge
Native gives you control Flutter abstracts away
Android background behavior can be unpredictable
Sometimes… you won’t have all the answers immediately

If you're building something serious:

Don’t just rely on abstractions. Understand what’s underneath.

That’s where real engineering begins.

Android official agent skills

Thu, 16 Apr 2026 12:12:52 +0000

The Android team has published an official repository of Agent Skills for Android development. The new android/skills repository is hosted under the official Android GitHub organization, and Android describes these skills as modular instructions and resources that help LLMs better understand and execute Android specific tasks according to best practices.

The github repo:
https://github.com/android/skills

The repository already shows the kind of workflows Android wants to support. Its current structure includes skills for AGP 9 upgrade work, XML Views to Jetpack Compose migration, Navigation 3, R8 analysis, Play Billing version upgrades, and edge to edge support. That makes the repository more than a generic demo. It is an initial curated set of focused Android engineering workflows.

React Native Android Build Failed: Could Not Resolve Dependency (Real Causes)

Mon, 13 Apr 2026 16:06:32 +0000

React Native Android builds can fail for a lot of reasons—but one of the most common (and confusing) ones is:

Could not resolve dependency

If you’ve seen this, you probably also noticed:

the error message is long
it looks very “Gradle-heavy”
and it doesn’t clearly tell you what to fix

Here’s what this error actually means—and how to approach it without wasting hours.

What “Could not resolve dependency” really means

This error usually appears when Gradle tries to fetch or link a dependency and fails.

But the important part is this:

it’s not always a network issue

Most of the time, it’s caused by something in your project setup.

1. Version mismatch (most common cause)

This is the #1 reason behind this error.

Examples:

a library requires a newer React Native version
your Gradle or Android plugin version is outdated
Kotlin version doesn’t match project setup

Even a small mismatch can break dependency resolution.

2. Repository configuration issues

Gradle needs to know where to download dependencies from.

Check your build.gradle files for:

mavenCentral()
google()

If a required repository is missing, Gradle simply won’t find the dependency.

3. Incorrect or missing dependency declaration

Sometimes the issue is simpler than it looks:

typo in dependency name
wrong version specified
dependency removed or renamed upstream

In these cases, Gradle is doing exactly what it should—it just can’t find what you asked for.

4. Caching problems

Yes—sometimes it really is cache.

You might have:

corrupted Gradle cache
stale dependencies
partial downloads

Cleaning can help here:

cd android
./gradlew clean

But keep in mind:
if the issue is structural, cleaning won’t fix it

5. Network / proxy issues

Less common, but still possible:

blocked connections
corporate proxies
SSL issues

If Gradle can’t reach the repository, dependency resolution fails.

6. Autolinking side effects

Sometimes this error shows up after installing a new package.

What’s happening:

the package introduces native dependencies
Gradle tries to resolve them
something in the chain fails

This is why the error often appears right after adding a library.

How to debug it faster

Instead of reacting to the full error message, do this:

Look for the exact dependency name that failed
Check its version compatibility
Verify your repositories
Connect it to the last change you made

This approach is much faster than trying random fixes.

Final thoughts

“Could not resolve dependency” sounds like a simple error—but it can come from multiple causes:

version mismatches
missing repositories
incorrect dependencies
caching issues

If you treat it as a category of problems instead of a single issue, debugging becomes much easier.

And in most cases, the fix is simpler than it first appears.

Building OneRule: A Technical Deep Dive into an Offline Password Manager with Flutter, SQLCipher, and AES-GCM

Mon, 13 Apr 2026 12:48:19 +0000

Password managers often get discussed at product level: sync, UX, pricing, recovery, browser extensions.

What interested me more in OneRule was lower in stack:

what "offline-first" actually means in implementation
how local key derivation is handled
where encryption boundaries sit
how Flutter and native Android divide responsibility

OneRule is an open-source Android password manager built with Flutter. It does not require an account or backend for core vault operations. The interesting part is not only that it works offline, but that the architecture is intentionally shaped around that constraint.

This post is a technical walkthrough of current implementation: storage model, key flow, backup format, panic mode behavior, and Android Autofill boundary.

Architectural Shape

At code level, OneRule follows a fairly direct layered structure:

Flutter UI for screens, forms, and interaction flows
Provider-based state for app-level reactive data
service and facade classes for storage, crypto, backup, auth, clipboard, and platform integration
native Android code where platform APIs are necessary, especially Autofill

In practical terms, the flow looks like this:

UI/screens
  -> Provider state
    -> service/facade layer
      -> SQLCipher / secure storage / crypto / platform channels

This is not an especially exotic architecture, but it fits security-sensitive mobile software well. UI code stays mostly unaware of encryption details. Providers coordinate visible app state. Services own the mechanics of vault initialization, field encryption, backup creation, and unlock behavior.

For a Flutter app, that separation matters because it reduces chances that sensitive logic leaks into widget code and becomes harder to reason about.

The startup path is also explicit about local protections. On launch, the app initializes error handling and reminder services, then enables screen-capture protections before rendering UI:

void main() async {
  WidgetsFlutterBinding.ensureInitialized();
  await LocalLogService.instance.initializeGlobalErrorHandlers();
  await BackupReminderService.instance.initialize();

  if (Platform.isAndroid || Platform.isIOS) {
    await ScreenProtector.preventScreenshotOn();
    await ScreenProtector.protectDataLeakageOn();
    await ScreenProtector.protectDataLeakageWithBlur();
  }

  runApp(/* providers + app */);
}

That is small, but it shows something important about OneRule: operational security controls are part of app bootstrap, not optional polish added later.

Data-at-Rest Model

The vault is not stored as plaintext records in local SQLite.

OneRule uses SQLCipher-backed SQLite as the primary vault store. The database file is encrypted at rest, and the SQLCipher password is derived from the active in-memory session key.

But the design does not stop there.

The password field is also encrypted again at application level using AES-256-GCM. So the current storage model is effectively:

encrypted database file via SQLCipher
encrypted sensitive field payloads inside that database

That second layer is important. It means the most sensitive credential field is stored and serialized as an authenticated encrypted envelope, not only as a row protected by database-level encryption. When the Flutter app needs to render or analyze entries, it decrypts that field at read time.

The current field payload format is versioned and structured like this:

or1:v2:gcm:<nonce_b64url>:<cipherText_b64url>:<tag_b64url>

Using a versioned envelope instead of opaque bytes makes future migrations much easier. It also gives the app a clean way to distinguish between:

current AES-GCM records
legacy AES-CBC records
pre-envelope data from older versions

That matters because OneRule includes migration logic and does not assume the vault will always start in latest format.

For backups, the code takes the same approach: explicit envelope, explicit metadata, explicit version.

Key Derivation and Session Model

The master PIN is not used directly as an encryption key.

Instead, OneRule derives key material with PBKDF2-HMAC-SHA256. Current implementation uses:

100,000 iterations for interactive PIN unlock/session derivation
256-bit output
16-byte random salts

Backup encryption uses a separate derivation profile:

PBKDF2-HMAC-SHA256
200,000 iterations
256-bit output
16-byte random salt embedded in backup payload

That separation is a good design choice. Unlock flows need acceptable latency on-device. Backup export and import can afford a higher work factor because they are less frequent and less latency-sensitive.

The session model is also worth calling out:

the active vault session key is kept in memory
SQLCipher password is derived from that key
secure storage holds salts, verifiers, and biometric-restorable material
session key is cleared on logout and lock paths

So the app has a fairly explicit distinction between:

persistent verification or recovery metadata
active decrypted session state

That is small but important. A lot of local-first security design is really state-lifecycle design.

Backup derivation path is straightforward and readable in code:

Future<SecretKey> _deriveKey(String passphrase, List<int> salt) async {
  final pbkdf2 = Pbkdf2(
    macAlgorithm: Hmac.sha256(),
    iterations: _pbkdf2Iterations,
    bits: 256,
  );
  return pbkdf2.deriveKey(
    secretKey: SecretKey(utf8.encode(passphrase)),
    nonce: salt,
  );
}

Then the payload is encrypted with AES-GCM using fresh salt and nonce:

final salt = _randomBytes(16);
final nonce = _randomBytes(12);
final key = await _deriveKey(passphrase, salt);

final secretBox = await _gcm.encrypt(
  utf8.encode(plaintext),
  secretKey: key,
  nonce: nonce,
);

Why SQLCipher Plus Field-Level AES-GCM?

A reasonable question is: if SQLCipher already encrypts database file at rest, why encrypt the password field again?

The answer is separation of concerns.

SQLCipher protects the database as a container. Field-level AES-GCM protects the most sensitive payloads as application-managed cryptographic objects with explicit integrity tags and versioned envelopes.

That gives OneRule a few advantages:

clean migration path from old formats to new ones
explicit tamper detection at field level
easier reuse of encrypted credential payloads outside normal Flutter list rendering
tighter control over what can be serialized or handed to native layers

The Android Autofill integration benefits directly from this. More on that later.

Vault Migration Strategy

OneRule still contains migration support for older storage models.

There are two migration stories in current codebase:

1. Legacy vault backend migration

Older vault data could exist in Hive-based storage. Current architecture uses SQLCipher, and the app includes a one-time migration reader that imports legacy records into encrypted SQLite, then removes old box data and marks migration complete.

2. Legacy cipher format migration

Password payloads and backup payloads have moved from older layouts into AES-GCM-based envelopes.

For vault records, the app can still read:

legacy CBC envelope format
older marker-based GCM payloads
older plaintext-style legacy values

On unlock, rows are scanned and migrated into current or1:v2:gcm format. Migration is designed to be non-lossy:

read legacy payload
decrypt or parse
re-encrypt in latest format
persist migrated value

If crypto validation fails, migration hard-fails rather than overwriting questionable data.

That is exactly what you want in security migration code. Silent best-effort conversion is dangerous when integrity matters.

Backup Format and Cryptographic Container

Offline-first apps still need a portability story. Otherwise "no sync" quickly turns into "single-device risk."

OneRule handles that with encrypted backup export and import. Current export format is a JSON-based .enc container with schema version v: 3.

The backup pipeline looks like this:

collect vault records
serialize plaintext JSON
derive encryption key from backup passphrase using PBKDF2-HMAC-SHA256
encrypt with AES-256-GCM using random nonce
emit structured JSON container with metadata

The container includes:

KDF metadata
cipher metadata
salt
authenticated encryption envelope
creation timestamp
item count

That is a much better design than "just encrypt some bytes and hope future versions remember how." Explicit metadata makes forward migration, compatibility handling, and debugging safer.

Current backup writer emits a structured object like:

return {
  'v': _backupSchemaVersion,
  'envelope': {
    'format': 'onerule-backup',
    'version': 'v3',
    'algorithm': _gcmAlgorithmName,
    'nonce': base64UrlEncode(secretBox.nonce),
    'cipherText': base64UrlEncode(secretBox.cipherText),
    'tag': base64UrlEncode(secretBox.mac.bytes),
  },
  'salt': base64UrlEncode(salt),
  'kdf': {
    'algorithm': 'PBKDF2-HMAC-SHA256',
    'iterations': _pbkdf2Iterations,
    'keyBits': 256,
  },
};

That snippet captures design philosophy well: crypto parameters travel with container, not only with developer memory.

Import path is also backward-compatible with:

current .enc encrypted backups
legacy .onerule extension
previous schema v: 2
previous schema v: 1, including legacy CBC layout

Again, the pattern here is versioned crypto container plus explicit readers, not hidden magic.

Panic PIN and Privacy Flow

Panic mode is one of the more interesting product decisions because it crosses UX, threat modeling, and implementation details.

OneRule supports a separate Panic PIN verifier. When this flow is used, the app avoids exposing the real vault and enters a privacy-focused decoy mode.

There are two implementation details worth noting:

provider state sets panic mode and suppresses real vault data
home screen renders decoy credential entries for that mode

That means panic mode is not implemented as "delete everything" or "rename list to empty." It is an explicit alternate UI and state flow.

This is a subtle but meaningful distinction. Security-sensitive UX should not depend on the user remembering whether a blank screen is real, broken, or intentional.

The app also warns users that panic mode is a decoy flow and can be confusing if triggered accidentally. That kind of warning is good product engineering. Safety features that are easy to misunderstand become liabilities.

Android Autofill Boundary

Password managers live or die on ergonomics, and Android Autofill is one place where architecture decisions show up clearly.

OneRule uses a native Android AutofillService for API 26+ and bridges it from Flutter over a platform channel. The relevant boundary is important:

Flutter owns normal vault UX and decrypted entry access after unlock
Flutter syncs an encrypted credential snapshot to native storage
Flutter also provides a session key to native layer for active unlock window
native Autofill service performs decryption only when it needs to fill a request

That means Autofill is not backed by a permanently stored plaintext cache. Instead, encrypted envelopes are synced to native side, and usable decryption depends on active session state.

The platform methods reflect that design:

syncAutofillCredentialSnapshot
setAutofillSessionKey
clearAutofillSessionKey

If session key is cleared on lock/logout, Autofill stops returning datasets.

Flutter side bridge is intentionally thin:

Future<void> syncCredentialSnapshot({
  required String payload,
  required String sessionKeyBase64,
}) async {
  final state = await availability();
  if (state != AutofillMvpAvailability.available) {
    return;
  }
  await _bridge.setSessionKey(sessionKeyBase64);
  await _bridge.syncCredentialSnapshot(payload);
}

That sequence matters. Native side receives encrypted snapshot plus active session key only when feature is available and vault is in usable state.

This is a strong boundary design because it minimizes plaintext residency and ties Autofill usefulness to vault unlock state rather than treating Autofill as a separate always-on data channel.

Locking, Clipboard, and Leakage Controls

Security work is often ruined by small post-decrypt leaks rather than broken cryptography.

OneRule includes several controls in this category:

screenshot prevention and screen-capture leakage protection on mobile
auto-lock timeout based on app lifecycle transitions
clipboard auto-clear after configurable delay
optional application of clipboard policy to usernames as well

The lifecycle lock path is especially relevant in Flutter apps, where it is easy to focus on route state and forget process state. OneRule tracks pause/resume transitions and clears session state when idle time exceeds configured threshold.

The relevant branch in lifecycle observer is simple and effective:

if (diff.inSeconds > timeoutSeconds) {
  storage.clearSessionKey();
  unawaited(PlatformCredentialProvider().onVaultLocked());
  unawaited(context.read<PasswordProvider>().lockForSession());
  Navigator.of(context).pushAndRemoveUntil(
    MaterialPageRoute(builder: (_) => const LoginScreen()),
    (_) => false,
  );
}

That is exactly kind of code I like seeing in security-sensitive mobile apps: short, direct, and tied to explicit state invalidation.

That is not glamorous, but it is real security work.

Vault Health Analysis

OneRule also includes a local "Vault Health" analyzer. This is not cryptography, but it is useful security-adjacent logic.

The current report model scores the vault from 0 to 100 based on:

weak passwords
exact-match duplicate passwords
stale credentials

Duplicate detection uses local hash-based comparison logic rather than remote checks, which keeps analysis offline and aligned with rest of system design.

This is a good example of how offline-first does not need to mean feature-light. You can still deliver useful security insights locally if the data model and processing path are designed for it.

Why Flutter Works Here

Security software is often assumed to require fully native implementation, but OneRule is a good example of when Flutter is enough for most of stack and native code is reserved for true platform edges.

Flutter handles:

application UI
state management
settings and backup flows
vault rendering and search
generator and health screens

Native Android handles:

Autofill service
platform-specific storage and bridge responsibilities
native crash logging hooks

That is a practical split.

Flutter gives fast iteration and a unified codebase. Native code stays focused on surfaces where Android APIs are non-negotiable. For a solo-built security product, that balance can make a big difference in maintainability.

Threat Model Boundaries

Good security writeups should include limits, not only protections.

OneRule is designed to defend against:

offline access to copied app data without the derived key
theft or exfiltration of encrypted database files
tampering of AES-GCM protected vault fields and backups

It is not designed to fully defend against:

rooted or fully compromised operating systems
malware with runtime access while vault is unlocked
PIN disclosure by user coercion, phishing, or keylogging
clipboard interception before auto-clear executes

That is a reasonable and honest scope. Offline encryption can do a lot. It cannot fix a hostile runtime after trust boundary is already lost.

Why This Project Is Interesting

A lot of apps claim privacy because they do not have obvious ads or trackers. OneRule is more interesting than that because privacy is expressed in structure:

no backend dependency for core vault flows
explicit key derivation
versioned encrypted payloads
layered storage protection
local-only backup generation
native Autofill integration without persistent plaintext snapshot model

This is what I like about the project technically. The product promise and implementation choices mostly line up.

That is rarer than it should be.

Closing

If you want to study a Flutter security app that takes local-first architecture seriously, OneRule is worth reading through.

It is not trying to out-feature every cloud password manager. It is solving a narrower problem: how to build a usable password vault where local storage, transparent cryptographic boundaries, and offline operation are first-class constraints rather than marketing copy.

Project links:

GitHub: https://github.com/seralifatih/OneRule
Google Play: https://play.google.com/store/apps/details?id=com.fidevelopment.onerule

If you build security software in Flutter, this kind of project is a useful reminder that "mobile-first" and "security-conscious" do not have to be opposites. With careful boundaries, versioned crypto payloads, and disciplined state handling, a local-first password manager can stay practical without outsourcing trust to infrastructure.

React Native Android Autolinking Issues: Common Problems and What to Check

Mon, 06 Apr 2026 16:56:36 +0000

Autolinking in React Native is supposed to simplify native module integration—but when it breaks, it can be frustrating and time-consuming to debug.

If your Android build is failing or a package isn’t being recognized, autolinking is often the root cause.

Here are the most common issues and what you should check.

1. Package not properly installed

Before diving deeper, make sure the dependency is correctly installed.

Check:

package.json includes the library
node_modules contains it
You’ve run:

npm install
# or
yarn install

If something feels off, delete and reinstall:

rm -rf node_modules
npm install

2. Missing or outdated Gradle sync

Autolinking depends on Gradle picking up native modules.

Try:

cd android
./gradlew clean

Then rebuild the project:

npx react-native run-android

3. Incorrect React Native CLI detection

Sometimes the React Native CLI doesn’t properly detect the module.

Run:

npx react-native config

Check if your dependency appears under:

dependencies
platforms.android

If it’s missing, autolinking is not working correctly.

4. Manual linking leftovers

If the project was upgraded or previously used manual linking, conflicts can occur.

Check:

MainApplication.java
settings.gradle
app/build.gradle

Remove any old manual linking entries.

5. Incompatible library version

Some libraries:

don’t support your React Native version
require additional setup

Always verify:

the library’s documentation
compatibility with your RN version

6. Android-specific configuration missing

Some packages still require manual steps.

Look for instructions like:

adding permissions in AndroidManifest.xml
modifying build.gradle
adding custom native code

Autolinking doesn’t cover everything.

7. Caching issues

React Native and Gradle caching can cause stale builds.

Try clearing everything:

watchman watch-del-all
rm -rf node_modules
rm -rf android/build
rm -rf android/app/build
npm install
cd android && ./gradlew clean

Final thoughts

Autolinking issues usually come down to:

installation problems
Gradle not syncing correctly
leftover manual configurations
version incompatibilities

Instead of guessing, go step by step through these checks—you’ll usually find the issue faster.

If you’re working a lot with React Native Android builds, you’ll notice most errors fall into a few recurring patterns like these.