I'm stuck on a Google Play subscription issue and wondered if anyone has run into the same sequence.

It's a native Android Java app using Play Billing 9.x. An internal-test release exists, but the failing builds are locally test-signed APKs installed directly, using the same package name. Production isn't live yet.

Here's what happens:

- A fresh ProductDetails query succeeds and returns the expected monthly plan and offer token.

- We pass those matching details and token into the purchase request.

- launchBillingFlow returns OK (0).

- Google then displays: "The item that you were attempting to purchase could not be found."

- PurchasesUpdatedListener returns ITEM_UNAVAILABLE (4), sub-response 0, with no useful debug message captured.

We've now logged two monthly attempts end to end. One sent both obfuscatedAccountId and obfuscatedProfileId. The other omitted the optional profile ID completely, keeping the account field. The logs confirm that change, with matching account-identifier and offer-token digests and subscription terms. Both failed the same way, so omitting the profile ID didn't fix it. The full builds also differ in test controls, so we're not claiming a perfectly isolated comparison.

A few other details:

- All three Google accounts on the phone are in the licence-testing list, and we've tried the flow with all three at different times without resolving it. We haven't captured which Google account actually handled each failed checkout; selecting a Play Store profile alone doesn't prove that.

- Earlier Console checks showed active base plans, and later queries returned regular offers for the configured test country.

- Clean reinstalls haven't resolved it.

- Another app from the same developer has completed licence-test purchases on this phone.

- We haven't yet recorded a like-for-like comparison using a build installed through Play, or independently verified each account's internal-test opt-in.

The app also has separate one-time add-ons. We previously changed our app/backend rules so new add-on purchases require an active subscription. Some commerce code is shared, so we're considering whether those changes are relevant, but haven't found a connection. The failing request contains just one SUBS item, not a mixed subscription/add-on purchase.

No payment was confirmed in the latest test and no purchase receipt was observed. Google support has the logged failures, but so far we've only had acknowledgements.

Has anyone seen product lookup succeed and launchBillingFlow return OK, only for Google to reject the purchase asynchronously like this? What turned out to be the cause?

In particular, is there a useful way to check the actual payer/licence-tester recognition when the normal payment sheet never appears? And could internal-test opt-in still explain this for a licence tester using a sideloaded build, or is there something else in the request or Console setup we should be checking?

I've seen plenty of Android tutorials showing how to recreate the Matrix digital rain effect, but when I looked for a reusable library I could simply integrate into an existing app, I couldn't find what I was looking for.

So I built one.

"matrix-rain-view" is an open-source Android library that renders the effect directly on a "Canvas" — no GIFs, Lottie animations, or video backgrounds.

It's designed to be integrated into actual applications, with features including:

• 🟢 Customizable colors, glyphs, speed, and density
• ⚡ Glitch effects and touch-reactive interactions
• 🌊 Shockwaves and interactive rain streams
• 🫥 Transparent rendering for overlaying existing UI
• 📱 Android View and Jetpack Compose integration
• ♻️ Lifecycle-aware animation
• 👀 Still involving

The goal isn't just to recreate the effect in a demo. It's to make it something Android developers can actually use in their own projects.

🔗 GitHub: Repo

I'm especially interested in feedback from Android developers: What would you build with this, and what would make integrating it into your apps easier?

If you've encountered another reusable Android library specifically for the Matrix digital rain effect, I'd genuinely like to see it too. I'm curious about what already exists in this space.

Hey everyone,

I recently built and deployed two native Android applications using Kotlin and Android Studio, focusing on optimized app performance and monetization integration.

1. Tech & Placement Quiz App

* Features: Curated questions on DSA, Core CS, Quantitative Aptitude (SSC CGL/Placement level), and 2026 Current Affairs.

* Tech: Integrated Start.io SDK for monetization and built dynamic deduplication logic using SharedPreferences to prevent repeating questions in sessions.

* 🔗 Dawnload : https://ankursinhagames.itch.io/quiz-app

1. Flappy Bird 2D Game

* Features: Custom Canvas rendering, frame-rate responsive touch physics, dynamic obstacle generation, and local high-score tracking.

* Tech: Integrated Start.io SDK for ads.

* 🔗 Dawnload : https://ankursinhagames.itch.io/sky-dash

Would love to get your thoughts on the code structure, UI/UX, and performance. Feedback and suggestions are highly appreciated!

[BUSCO PROGRAMADOR] App para falsificar pasos en Walking y WalkTask

¡Hola a todos! 👋

Tengo una idea para desarrollar una aplicación llamada Walking, cuyo objetivo sería simular caminatas para que aplicaciones como WalkTask puedan detectar pasos aunque el usuario no esté caminando físicamente.

(link: https://discord.gg/ftrxM8zy )

Actualmente busco un programador interesado en colaborar conmigo para hacer realidad este proyecto. La idea es desarrollar una app funcional, sencilla de utilizar y compatible con las aplicaciones que se quieran integrar, siempre que sea técnicamente posible.

💰 Sobre el pago:

Quiero ser totalmente transparente: actualmente no cuento con presupuesto para pagar el desarrollo por adelantado. Mi propuesta es que, una vez terminada la aplicación, pueda empezar a generar ingresos con ella para pagarle al programador por su trabajo.

Entiendo que esto implica un riesgo y que no todo el mundo estará interesado en trabajar bajo estas condiciones. Por eso, me gustaría acordar desde el principio una cantidad, las condiciones del pago y cómo se repartirían los posibles ingresos.

🔎 ¿Qué busco?

• Un programador con conocimientos de desarrollo de aplicaciones Android.
• Alguien interesado en colaborar en un proyecto desde cero.
• Compromiso, comunicación y ganas de crear algo útil.

Si te interesa la idea o quieres conocer más detalles, puedes escribirme por mensaje privado. ¡También agradezco consejos y sugerencias para hacerla realidad!

link del grupo:https://discord.gg/ftrxM8zy

Gracias por leer. 🙌

REA Claims It Can Reverse Engineer Any App. Can XopProtector Help Protect Your Android App in the AI Era?

How XopProtector Provides an Additional Layer of Protection Against AI-Assisted Reverse Engineering

Recently, REA (Reverse Engineer Anything) has attracted attention in the open-source reverse-engineering community.

As an AI-driven reverse-engineering agent framework, REA represents a growing trend: combining large language models with traditional reverse-engineering tools to automate parts of the analysis process.

By integrating tools such as JADX, Ghidra, and IDA into an AI-assisted workflow, reverse engineers can analyze application code, trace call relationships, understand program structures, and investigate business logic more efficiently.

In the past, analyzing an APK often required an experienced reverse engineer to spend days or even weeks examining code, writing scripts, and debugging the application.

With AI assistance, some of these tasks can be completed much faster.

This raises an important question for Android developers:

In an era of AI-powered reverse engineering, how can we protect the business logic inside our applications?

The answer is not to abandon application protection. It is to move beyond basic obfuscation.

1. Why Is REA a Concern for Android Developers?

A traditional APK reverse-engineering workflow often looks like this:

APK
 ↓
Extract classes.dex
 ↓
JADX / IDA
 ↓
Manual Analysis
 ↓
Understand Business Logic

This process relies heavily on the reverse engineer's experience.

With AI assistance, the workflow can become:

APK
 ↓
Decompiler
 ↓
REA / AI-Assisted Analysis
 ↓
LLM
 ↓
Faster Code Understanding

AI's biggest advantage is not simply reading code. It is inferring the meaning behind code.

Consider the following example:

boolean checkPermission(User user) {
    return user.level >= 10;
}

Even after basic obfuscation:

boolean a(b c) {
    return c.d >= 10;
}

an AI model may still infer that this method performs a permission-level check based on its parameters, call sites, return value, and surrounding context.

That is why simply renaming classes and methods is becoming less effective as a standalone protection strategy.

2. Why Can Basic Android Protection Fall Short?

Many basic protection solutions focus on wrapping an APK or encrypting its DEX files.

A simplified workflow looks like this:

Original DEX
     ↓
DEX Encryption / Packing
     ↓
Runtime Decryption

This can make direct static analysis more difficult. However, if an attacker successfully extracts the original DEX from memory, the recovered code may once again be accessible to standard analysis tools.

The workflow then becomes:

Protected APK
     ↓
Recover DEX
     ↓
JADX
     ↓
REA / LLM
     ↓
Analyze Business Logic

The important distinction is that REA does not need to break every protection mechanism itself to be useful. If an attacker has already recovered readable code, AI can help analyze that code much more efficiently.

Basic obfuscation and packing may increase the initial effort, but they do not necessarily prevent the recovered code from being analyzed.

This is where more advanced protection techniques become relevant.

3. Understanding the Limits of AI Reverse Engineering

Does the rise of AI mean that every APK can now be reverse-engineered automatically?

Not necessarily.

AI-assisted analysis still depends on the information available to the tools.

For example, AI works well with representations such as:

Java
 ↓
Smali
 ↓
Standard Instructions
 ↓
Semantic Analysis

But when an application uses custom virtual instructions, runtime code loading, and a specialized execution environment, the analysis process becomes more complicated.

An AI agent may need to determine:

• What each custom VM instruction means
• How the virtual machine executes those instructions
• How the original control flow is represented
• How to reconstruct the protected business logic

A general-purpose reverse-engineering agent should not be assumed to automatically solve every custom virtualization scheme.

However, this does not mean such schemes are impossible to reverse-engineer. A sufficiently capable analyst can still investigate the virtual machine and its execution behavior.

The key point is that custom virtualization can change the reverse-engineering problem rather than merely make the original code harder to read.

4. How Is XopProtector Different from Basic Protection Solutions?

XopProtector is an open-source Android application protection project that uses multiple protection mechanisms rather than relying exclusively on basic code obfuscation.

Its protection approach includes technologies such as:

• DEX protection and dynamic loading
• PVM-based custom virtual-machine execution
• Method-level code virtualization
• Native .so protection
• RASP runtime protection

Conceptually, the architecture can be represented as:

                   APK
                    |
          +---------+---------+
          |                   |
     DEX Protection      Method Virtualization
          |                   |
          v                   v
    Dynamic Loading       PVM / VMP
          |                   |
          +---------+---------+
                    |
                Native SO
                    |
                   RASP

The objective is not simply to hide code names. It is to change how protected code is stored, represented, loaded, and executed.

Let's examine the main protection layers.

5. First Layer: DEX Protection and Dynamic Loading

In a conventional APK, application logic is commonly stored in DEX files:

APK
 └── classes.dex
      └── Application Code

An attacker can extract the DEX and attempt to decompile it directly.

A protected application may instead use a structure resembling:

APK
 ├── Shell
 ├── Protected DEX Data
 └── Native Loader

At runtime, the protection mechanism handles the necessary loading and execution operations.

Native Loader
      ↓
Decryption / Loading
      ↓
Runtime
      ↓
Application Execution

This can reduce the amount of useful application code exposed during static analysis.

When an attacker initially opens a protected APK in JADX or submits it to an AI analysis workflow, the original business logic may not be directly available in its usual form.

However, dynamic loading alone does not guarantee that the code cannot be recovered. A determined attacker may attempt memory analysis or runtime instrumentation.

The value of this layer is that it introduces additional obstacles before meaningful code analysis can begin.

6. Second Layer: PVM / VMP Virtualization

One of the most important differences between ordinary obfuscation and virtualization is how the code is represented.

Traditional Android code follows a familiar execution path:

Java / Kotlin
      ↓
     DEX
      ↓
    ART

With code virtualization, selected methods can instead be transformed into custom virtual instructions and executed through a dedicated virtual-machine runtime.

Conceptually:

Original Code
      ↓
Custom Virtual Instructions
      ↓
Native VM Interpreter
      ↓
Execution

For example, an original method might contain logic such as:

if (password.equals(key)) {
    login();
}

After virtualization, the protected logic may no longer appear as an ordinary Java method with the same recognizable structure.

An attacker must first understand the custom instruction set and the interpreter before attempting to reconstruct the original semantics.

The analysis process becomes:

1. Analyze the VM interpreter.
2. Determine the meaning of its virtual instructions.
3. Reconstruct the virtualized control flow.
4. Recover the underlying business logic.

This is a substantially different task from simply renaming variables or classes.

The key advantage of virtualization is that it can increase the cost of recovering protected logic, including for AI-assisted analysis workflows.

It does not make reverse engineering mathematically impossible, but it can make automated analysis less straightforward.

7. Third Layer: Native .so Protection

Modern Android reverse engineering is not limited to Java and DEX.

Attackers may also investigate:

• Native shared libraries
• JNI calls
• ARM / ARM64 assembly
• ELF structures
• Memory layouts
• Native control flow

XopProtector incorporates Native-layer protection into its broader architecture.

Depending on the protected component, Native code can contain important runtime and protection logic.

This adds another analysis layer:

Java / Kotlin
      ↓
     DEX
      ↓
 Protection Layer
      ↓
 Native Runtime
      ↓
 VM / RASP

Native analysis may require additional work involving assembly, memory operations, dynamic linking, and JNI behavior.

When Native protection is combined with virtualization and other obfuscation techniques, the attacker may need to understand several interacting components rather than simply decompile a DEX file.

This can make AI-assisted reconstruction more difficult and time-consuming.

8. Fourth Layer: RASP Against AI-Assisted Dynamic Analysis

AI-assisted reverse engineering is not limited to static code analysis.

An attacker may combine AI with tools such as Frida and dynamic debuggers to inspect application behavior.

A simplified workflow looks like this:

AI
 ↓
Analyze Target Function
 ↓
Generate Hook Script
 ↓
Run Application
 ↓
Capture Runtime Data
 ↓
Analyze Results
 ↓
Generate Additional Scripts

This creates an automated feedback loop between code analysis and runtime observation.

Protecting the static DEX is therefore only part of the problem.

XopProtector incorporates RASP-oriented runtime protection capabilities that can help detect suspicious execution environments, depending on the implementation and configuration.

Such mechanisms may include:

• Anti-debugging checks
• Hook detection
• Application integrity verification
• Signature verification
• Runtime environment checks

When suspicious activity is detected, an application may respond according to its protection policy.

These mechanisms can increase the difficulty of automated runtime analysis, although their effectiveness depends on the detection coverage, implementation quality, and attack environment.

No individual RASP mechanism can guarantee that every debugging or instrumentation attempt will be detected.

9. Traditional Obfuscation vs. XopProtector

The following table provides a high-level comparison of the different approaches.

This comparison describes the general technical approaches, not a guarantee that every feature will be enabled for every application or that XopProtector will outperform every commercial product in every scenario.

The actual protection level depends on the configuration, the code being protected, platform compatibility, and the attacker's capabilities.

10. What Is the Real Goal of Android Protection in the AI Era?

It is important to be realistic: no Android protection solution can guarantee permanent resistance to reverse engineering.

Any application executing on a device controlled by an attacker may expose information through runtime behavior, memory inspection, instrumentation, or other techniques.

The goal of protection is therefore not to promise that an application can never be cracked.

The goal is to increase the effort required to recover valuable information.

With basic protection, an attack might look like:

APK
 ↓
Extract DEX
 ↓
Decompile
 ↓
AI-Assisted Analysis

With multiple protection layers, an attacker may need to perform additional work:

Protected APK
      ↓
Analyze the Protection Layer
      ↓
Investigate Runtime Loading
      ↓
Recover Protected Code
      ↓
Understand Custom VM Instructions
      ↓
Analyze Native Components
      ↓
Handle Runtime Protections
      ↓
Reconstruct Business Logic

Not every attack will follow this exact sequence, and some steps may be bypassed. Nevertheless, multiple independent protection mechanisms can increase the overall analysis cost.

That is the practical value of a layered protection strategy.

11. Why Consider XopProtector?

As AI-assisted reverse-engineering tools become more accessible, relying exclusively on identifier renaming is increasingly difficult to justify for applications containing high-value intellectual property.

If your Android application contains:

• Proprietary algorithms
• Licensing and authorization logic
• Payment-related business rules
• Valuable business workflows
• Sensitive client-side processing

then it may be worth considering protection beyond basic obfuscation.

XopProtector offers an open-source approach that combines DEX protection, code virtualization, Native-layer mechanisms, and runtime protection.

Its main value is the opportunity to build a more layered defense without relying exclusively on a closed-source commercial solution.

As with any protection product, developers should evaluate the actual implementation, supported Android versions, device compatibility, startup performance, APK size impact, and runtime stability before deploying it to production.

The best protection strategy is one that increases reverse-engineering costs without compromising the reliability of the application.

Conclusion: AI Is Making Reverse Engineering Faster. Protection Must Evolve.

REA represents a broader trend in software security: AI is making code analysis more accessible and automating tasks that once required substantial manual effort.

But faster code analysis does not automatically mean every protection mechanism becomes ineffective.

AI-assisted reverse engineering still depends on the code representations, runtime information, and analysis capabilities available to it.

XopProtector takes a layered approach through:

• DEX protection
• Dynamic loading
• PVM / VMP virtualization
• Native-layer protection
• RASP runtime defenses

These techniques can make it more difficult to obtain and reconstruct protected business logic than relying on simple identifier obfuscation alone.

The goal is not to claim that AI can never reverse-engineer a protected application. The goal is to make the process significantly more difficult, more expensive, and less straightforward to automate.

In the AI era, Android application security needs to evolve beyond hiding class and method names.

For developers looking for an open-source Android protection solution, XopProtector is worth evaluating as part of a broader application security strategy.

Project Links

• REA: https://github.com/morluto/rea
• XopProtector: https://github.com/xopJack/XopProtector

Disclaimer: This article discusses general protection concepts and potential benefits. Actual protection effectiveness depends on the implementation, configuration, target application, Android environment, and attacker's capabilities. No protection solution can guarantee absolute resistance to reverse engineering.

REA Claims It Can Reverse Engineer Any App. Can XopProtector Help Protect Your Android App in the AI Era?

I created some that should be helpful for Android and made this demo with them.

I'm interested in hearing other ideas.

https://youtu.be/Y3X5rz9pH5c

Hi everyone. I have decided to move my Android studio development off of windows and over to Fedora workstation.

It seems I have an install choice of using jetbrains or typical tar.gz

Anyone have any thoughts on what’s best?

I think it’s interesting jetbrains itself is a tar.gz and not a package.

I was using AI to perform my backup. My app was very nice. I needed to fix a couple small problems.
Gemini wiped out everything and even destroyed my backups.
Now, an App that I built for about 100 dollars, I'm rebuilding, and It has already cost me over 400 and Gemini seems to have become non-productive.
Tonight it is running sooo slow.
I thought I'd be better off using AI than coding myself and just directing.
What version if any are you using with Studio.

O objetivo é colocar uma imagem no local da câmera

Was wondering what all ChatGPT can do witj AndroidAuto as far as redesigning some screens I dont like. I have limited experience and not sure how to ask or tell it what exactly I want to do an such.. thanks in advance for any tips, tricks or anything else you can add!!

I use Claude Code a lot for Compose work. The annoying part was always the same: it writes a screen, says "done", and then I open Android Studio and the padding is off, text is clipped, or the dark theme is broken. It never saw the UI. It was guessing.

So I built Spyglass. It renders your u/Preview functions to PNG from the command line, no IDE open.

spyglass render --filter LoginScreen

What it does:

• Renders every u/Preview in a Compose Multiplatform project through your own Gradle wrapper. No changes to your build files.
• Handles u/PreviewLightDark, u/PreviewParameter, font scale, device sizes, and multi-preview annotations from other modules.
• Compares a render with a design image and tells you which regions differ, in dp, with a heatmap. So "make it match the Figma export" becomes something you can check.
• spyglass approve / spyglass check gives you screenshot tests in CI. A one-digit text change fails the check.
• Comes with an MCP server, so Claude Code, Cursor or anything that speaks MCP can render and look at the UI on its own and fix what it sees.

A few things I had to solve along the way that might be interesting:

• Animations and delay() in fake data. A naive render catches the first frame, so you get a progress bar at 0% and a dialog half faded in. Spyglass runs previews on a virtual clock until everything settles, so a delay(300) before your fake data loads costs no real time and you see the loaded state.
• A preview stuck in a loop used to hang the whole run. Now it gets cut off after 30 seconds and you get the exact line it was stuck on.
• Token cost for agents. Images are sized down, and if nothing changed since the agent last looked, it doesn't send the image again. A repeat render went from about 1,560 tokens to about 180.

Limits, so nobody is surprised: previews need a JVM (desktop) target, so Android-only previews and Android-only APIs don't render yet. Text uses your OS fonts, so keep screenshot baselines from one OS. Tested on Windows, Linux and macOS.

It's MIT licensed and this is the first release (0.1.0). I'd really like to hear where it breaks on your projects.

https://github.com/zainkhalid91/spyglass

I made this for android....can you tried and give your feedback ?

cos... no one is using....

Всем привет, Я начинающий разраб на Flutter & Dart и хочу писать приложения под мобилки. И почему то эмулятор в андроид студио включается и выходит за рамки моего экрана, что не так? Помогите пожалуйста)

Hi.
The news says building an AAB/APK should offer uploading it directly to my Play Console's test-track. Just... it doesn't. Any idea what I need to do? The dialog only says "yep, that package name is registered by a verified developer" - yea, that developer is me, I would like to upload now. But there's no such option. Also not after building the AAB completed.
Any ideas?

A year after deploying our application, Android Vitals and Firebase telemetry flags revealed a critical architecture defect: a 5% transaction drop rate and systematic crashes inside the core checkout flow on Android 13+.

De-obfuscation map logs pointed to a strict concurrency conflict between the Google Play Billing Library and our custom internal billing wrapper. Downgrading Google Billing was not an option. We had to rewrite the module in a live app without losing active subscriptions.

Here is the condensed 4-stage execution blueprint we used to overhaul the system during a 30-day sprint with zero downtime:

1. The Rollback Safety Valve (Feature Toggles)

• API Isolation: We decoupled the legacy module and isolated its public API behind strict interfaces.

• Twin Implementations: We maintained the legacy production code (Factory A) and created an exact cloned playground alongside it (Factory B).

• Remote Toggle: A remote feature toggle dynamically routed execution to either factory at runtime, providing an instant backend rollback mechanism if Factory B failed.

2. Testing Constraints (TDD)

Before modifying production code, we established strict boundaries: zero DB migration issues, zero performance drops over 10%, and a 95% Happy Path checkout success rate.

We sit down and developed 260 automated test cases covering roughly 88% of all possible failure states and network edge cases. No code was merged into the refactor branch without a 100% green CI/CD pipeline.

3. Execution & 5% Canary Release

• Stage 1: Overhauled the local state database layer, ran the suite until it turned green, and packaged it.

• Stage 2: Turned on the remote toggle rollout for only 5% of active users. Telemetry remained silent for 48 hours—no new crashes, no payment drops.

• Stage 3: Refactored the core business logic and direct billing API bindings under the same TDD cycle.

• Stage 4: Gradually increased the toggle from 5% to 100%. Once 88% of users updated, we deployed a cleanup release, deleting the toggle infrastructure and legacy code for good.

The Bottom Line (Metrics)

• Production Stability: Exactly one single bug slipped through the rollout.

• 1-Hour Mean Time to Repair (MTTR): Because the architecture was decoupled and backed by 260 tests, root-cause isolation took minutes. The fix was verified via TDD and hit production in under an hour.

• Maintainability: The system transitioned from a fragile black box into a highly predictable, self-documenting component.

Please I am loosing my mind. I am trying to do an android app for a class project but android studio is showing that almost all my imports and jet pack compose keywords (@Compose and things like that) are not resolving. I didn’t do anything custom just default settings and download sequence. I have tried some old fixes like clearing cache, deleting .idea and .gradle, syncing gradle, fixing IDE, cleaning the build but nothing works. I’m actually losing it because the file still compiles and runs on the emulator but it is soo annoying working without the comfort of linked files for fill in and quick jumping to definition and things like that.

If anyone has any help I would really appreciate it. Again it a fresh build so everything should be up to date except I made a catastrophic mistake during installation. Also the problem happens on any project I try to run, new or imported.

This infrastructure is great, but forget about it being comprehensive; there isn't even a normal app for supported devices.

https://github.com/qualcomm/geniex

I'm planning to build an app that makes enabling Developer Options easier, with a simple interface and less manual work. Would you use an app like this? Any suggestions are welcome!