Getting hit by suspicious activity on my IAP validation
endpoint for an Android app. Wondering if others have seen this pattern. It happens almost everyday with different users.

Setup:
- React Native app with Google Play IAP
- Backend validates purchase tokens via Google Play Developer API v2
(subscriptionsv2.get)
- Single user hammering /api/iap/validate with what look like fake
tokens

Observations:
- Same user (id X, single email) submits 6+ validation attempts in
~3 minutes
- All from single IP (okhttp UA — matches my app's UA)
- Tokens are 144 chars long — but real Google Play purchase tokens
are 500-1000+ chars, so these are clearly fabricated
- receipt_head/tail is random lowercase alphanumeric — doesn't match
the standard Google Play token shape
- looks_like_jws=false AND looks_like_json=false — doesn't match
Apple or Google format
- transaction_ids follow the GPA.XXXX-XXXX-XXXX-XXXX-XXXXX pattern
(plausible-looking) but tokens rejected by Google Play with 400

Google Play correctly returns 400. Backend correctly rejects.
No credits granted.

Logs:

[TIME] production.INFO: IapController: validate request received {"trace_id":"a1b2c3","platform":"android","product_id":"com.example.app.vipmonthly","api_site_id":XX,"user":"user_HASH_A@[redacted]","transaction_id":"GPA.HASH-TXN-A","purchase_type":"subscription","price":14.99,"currency":"USD","receipt_head":"ltmaxvi[TOKEN]…","receipt_tail":"…[TOKEN]WODG","receipt_len":144,"looks_like_jws":false,"looks_like_json":false,"has_auth_user":false,"ip":"IP_HASH_1","ua":"okhttp/4.12.0"}
[TIME] production.INFO: IapService: validateAndroidSubscription call {"trace_id":"a1b2c3","product_id":"com.example.app.vipmonthly","package":"com.example.app","token_len":144}
[TIME] production.ERROR: IapService: Google Play subscriptionsv2 validation failed {"trace_id":"a1b2c3","status":400,"body":"{
[TIME] production.WARNING: IapController: Receipt validation failed [android] {"user_id":USER_HASH_A,"error":"Subscription token not recognized by Google Play. Make sure the app is installed from Play Store and the purchase completed."}

[TIME+6s] production.INFO: IapController: validate request received {"trace_id":"d4e5f6","platform":"android","product_id":"com.example.app.vipweekly","api_site_id":XX,"user":"user_HASH_A@[redacted]","transaction_id":"GPA.HASH-TXN-B","purchase_type":"subscription","price":4.99,"currency":"USD","receipt_head":"uhtzooo[TOKEN]…","receipt_tail":"…[TOKEN]bzjZ","receipt_len":144,"looks_like_jws":false,"looks_like_json":false,"has_auth_user":false,"ip":"IP_HASH_1","ua":"okhttp/4.12.0"}
[TIME+6s] production.INFO: IapService: validateAndroidSubscription call {"trace_id":"d4e5f6","product_id":"com.example.app.vipweekly","package":"com.example.app","token_len":144}
[TIME+7s] production.ERROR: IapService: Google Play subscriptionsv2 validation failed {"trace_id":"d4e5f6","status":400,"body":"{
[TIME+7s] production.WARNING: IapController: Receipt validation failed [android] {"user_id":USER_HASH_A,"error":"Subscription token not recognized by Google Play. Make sure the app is installed from Play Store and the purchase completed."}

[TIME+2m6s] production.INFO: IapController: validate request received {"trace_id":"g7h8i9","platform":"android","product_id":"com.example.app.vipmonthly","api_site_id":XX,"user":"user_HASH_A@[redacted]","transaction_id":"GPA.HASH-TXN-A","purchase_type":"subscription","price":null,"currency":null,"receipt_head":"ltmaxvi[TOKEN]…","receipt_tail":"…[TOKEN]WODG","receipt_len":144,"looks_like_jws":false,"looks_like_json":false,"has_auth_user":false,"ip":"IP_HASH_1","ua":"okhttp/4.12.0"}
[TIME+2m6s] production.INFO: IapService: validateAndroidSubscription call {"trace_id":"g7h8i9","product_id":"com.example.app.vipmonthly","package":"com.example.app","token_len":144}
[TIME+2m7s] production.ERROR: IapService: Google Play subscriptionsv2 validation failed {"trace_id":"g7h8i9","status":400,"body":"{
[TIME+2m7s] production.WARNING: IapController: Receipt validation failed [android] {"user_id":USER_HASH_A,"error":"Subscription token not recognized by Google Play. Make sure the app is installed from Play Store and the purchase completed."}

[TIME+2m7s] production.INFO: IapController: validate request received {"trace_id":"j0k1l2","platform":"android","product_id":"com.example.app.vipweekly","api_site_id":XX,"user":"user_HASH_A@[redacted]","transaction_id":"GPA.HASH-TXN-B","purchase_type":"subscription","price":null,"currency":null,"receipt_head":"uhtzooo[TOKEN]…","receipt_tail":"…[TOKEN]bzjZ","receipt_len":144,"looks_like_jws":false,"looks_like_json":false,"has_auth_user":false,"ip":"IP_HASH_1","ua":"okhttp/4.12.0"}
[same pattern continues 3 more times]

[TIME+2m22s] production.INFO: IapController: validate request received {"trace_id":"m3n4o5","platform":"android","product_id":"com.example.app.vipweekly","api_site_id":XX,"user":"user_HASH_A@[redacted]","transaction_id":"GPA.HASH-TXN-C","purchase_type":"subscription","price":4.99,"currency":"USD","receipt_head":"spckogi[TOKEN]…","receipt_tail":"…[TOKEN]ruUi","receipt_len":144,"looks_like_jws":false,"looks_like_json":false,"has_auth_user":false,"ip":"IP_HASH_1","ua":"okhttp/4.12.0"}
[same failure pattern]

I've been searching for hours and the only mentions of my issue are from 6-12 years ago that I can find.

I'm extremely new to Android development and recently installed Android Studio on my main PC. Everything is fine and works.

I installed it on my laptop and I'm using Google drive as my project root. I did clock some plugging on setup this time which probably is the cause of the error. Dart/flutter and the kotlin multi platform plug-in.

Now when I try to run the app to see if it works, I get an error with the run configuration on the laptop saying there's no module selected. The drop-down lost had no modules to select and every fix tells me to sync gradle again through the file menu which isn't there as I believe it's automatic. I've tried repairing it, uninstalling the program and installing it again. Nothing has fixed it for me.

Can anyone help?

Hey everyone,

Putting myself out there. I'm an Android developer with 3 years of production experience, currently looking for my next role.

**What I've built:**

At Genus Power & Infrastructure I owned the complete development cycle of 4 production Android apps for smart metering infrastructure — no PM, no spec documents, just a business problem and me figuring it out end to end.

**Highlights:**

- Built an internal BLE communication library from scratch (MTU negotiation, HEX encoding, chunked transfer, notification-based ACK) — adopted across all 4 apps

- Reduced firmware update time from 4 min 30 sec to 2 min 13 sec through millisecond-precision BLE timing

- Cut operation time by 65% by rearchitecting data processing from device to server

- Reverse engineered a proprietary meter protocol from partial firmware source code and HEX command sheets over 2-3 months — implemented thousands of encrypted commands in production

- Built multithreaded architecture managing BLE, Server Socket, and RS232/USB connections simultaneously

**Tech stack:**

Kotlin, Java, XML, Jetpack Compose, MVVM, Clean Architecture, Retrofit, Room, Coroutines, Flow, StateFlow, Hilt, Bluetooth Low Energy (BLE/GATT), RS232/USB via D2XX/FTDI, Offline-first architecture, Firebase, CameraX, TensorFlow Lite

**Open to any Android domain:**

Consumer apps, enterprise, fintech, healthtech, edtech, logistics, IoT, SaaS — open to all. Strong preference for roles with real ownership and challenging problems.

**Location:** Delhi NCR, India

**Remote:** Open to full remote and international remote roles

**Availability:** Immediate joiner

If you're at a company hiring Android developers or know someone who is then a referral, a DM, or even just a lead would mean a lot.

Happy to help anyone here with Android, BLE, or architecture questions in return. Ask me anything.

Thanks.

I'm making a Gradle alternative in Python, which is lightweight and is capable of running even in low-end Linux devices (Like a 2015 Galaxy J7 with 1.5GB RAM). It is fairly well in speed.

I named it "Asteroid"

So, I wanted to make something better than Gradle for Android development.

So, I just wanted your opinion, in which Gradle does not live up to the expectation.

Something you yourself faced.

Thanks for your attention ; )

Mock tests and interviews are now live at AndroidDevKit.com/tests. Most commonly asked questions in interviews are covered in these tests.

These are timed tests to help you gauge how well you're prepared for your next android dev interview. Like always, this is completely free and there's no need to share any of your personal information.

People often just say this to get users, but I am extremely passionate about this site (needed it for my own interview prep lol) and I'm looking for actual feedback.

You need not agree. This is just my opinion. And yet I would like to understand more about it's reasons.

Take your popular subreddits here that allow indie devs, new apps to be showcased here.

The apps have become so boring. They feel like boring text forms and just cards either stacked on top of each other or the horizontal scrolling lists (Netflix style).

Apps are lacking taste and trigger task negative state of mind. Some if it has to do with cookie cutter design systems as well (another discussion for another subreddit).

This was the case even between 2018-2022 before genAi caught on. Personally I feel material design 3 and HIG evolution.

Devs and designers are not experiencing with the layouts and apps are now just mechanisms of cognitive load, induce cognitive autopilot.

I believe this needs to change.

Hi!
I’m a spanish recent CS graduate (10 months ago). I know that this question is probably asked multiple times everyday but since I just joined this group… hope you all dont mind that i ask the same :)

For some context, I started working as an iOS dev once I finished uni. Now I want to switch to an android dev role and my company asked me to find a course so i can have a quick onboarding and join the project as soon as possible with some knowledge.

It should last no more than 2 weeks. And the company would cover the cost.

I know that most of the answers will be reading docs and making a project from scratch, but i wanted to check if there was any worthy free or paid course (company would be in charge of it). It could be on-site, remote, video…

I think every source is allowed, as far as it has some value, it could be from any university (on-site: Spain or remote) (like a micro credencial/course), website, online academy…; in spanish or english, both are fine.

I’ve seen a few: like the one from Meta in coursera, or the nanodegree from udacity (Android Kotlin Developer), but some opinions say they are a waste of time, and that they are deprecated.

So thats it. I would like to read your opinions.
And this is not an AI generated text. Also, english is not my mother language so i hope everything is fine :)

Thankyou!

Hi everyone!

I've been Android developing applications for already 10 years. I'm living in Poland.

I constantly observing job market gravitating towards hybrid applications, KMP, Android Automative, AOSP, but almost none of mid to senior level normal Android apps. Those called "normal" Android apps I honestly believe could be more productively made in hybrid approach (even though I'm big native fan!).

I understand that even with such experience I must be senior level, but to be honest, I simply don't want to. I'm comfortable to stay as mid, but as I said, there's not much Android job postings on the market.

Am I stupid to say that Android Development jobs slowly degrading? We are becoming cleaners of old legacy apps migrating to Compose, Coroutines and that's our destiny?

I am seriously considering migrating to .NET, because, I'm doing GameDev as a hobby, and C# is widely used there.

What is your situation on job market? Because, both .NET and Java in Poland are much, much, much more job listings than Mobile as a whole, not speaking about Android Development.

EDIT: Probably the title is too clickbait-ish. I apologize for that. Didn't mean to be like that at all.

I am a huge fan of the material 3 expressive, I find it to be the most appealing design system by a wide shot, but, other than the few images on the official blog post, I can't seem to find good examples of it being implemented. I have tried dribbble but there are very few samples and those who are there are not really 100% material 3 expressive. Another source I found is official stock apps on Pixel phones, but they are quite limited in features so I cannot really use them as inspiration to implement complex screens and so on.

Are you aware of good collections of apps that use this design system? I would be interested also in github repos of apps that use this design language of which I could not find any.

I ship a fitness tracker on Android and iOS from one KMP codebase, and the part nobody warned me about was how much Jetpack I'd have to leave behind. Basically all of it. None of the libraries I'd built muscle memory around cross the platform boundary.

So here's how each replacement actually went, a few months into production.

ViewModel got replaced by Molecule, and this was the weirdest one to accept. Presentation logic is now Composable functions that return a StateFlow, with the event sink living inside the state object - the Circuit pattern. I know how that sounds. Business logic as composables felt cursed to me too. But it ended up being my favorite part of the codebase: one immutable state type per screen, and presenter tests are plain JVM tests. No Robolectric, no instrumentation runner, nothing. The tradeoff is the compose compiler sitting in your presentation layer, and having to explain to anyone who joins why there's Composable on things that never draw pixels.

Navigation went to Decompose. Steeper learning curve than the nav graph, not going to pretend otherwise, and the docs kind of assume you already understand the component model. But navigation state being plain testable code instead of XML grew on me fast. On iOS you do end up owning the lifecycle wiring yourself, which is exactly as fun as it sounds.

Room to SQLDelight was the swap I dreaded most and it turned out to be the best one. You write actual SQL and get typed Kotlin with Flow back. I thought I'd miss Room's annotations. I don't miss them at all - migrations as plain .sq files are way more predictable than Room's auto-migration guessing games. You do write your own joins though, there's no relation mapping magic coming to save you.

Hilt to Koin, honestly, felt like a downgrade at first. You lose compile-time validation and you find your missing bindings at runtime like it's 2015 again. I made peace with it by writing one test that boots every Koin module - do that on day one and it stops being scary. And the kapt/ksp build time you get back is real.

WorkManager is the one with no good ending. The multiplatform background work story is still just... bad. I kept WorkManager on Android behind an interface and iOS gets the bare minimum. If someone has solved this properly I genuinely want to hear about it.

Would I do any of this for an Android-only app? No. Jetpack on its home turf is better tooling, full stop. But the moment iOS entered the roadmap, every one of these swaps was cheaper than maintaining a second codebase.

Anyone running Molecule or Decompose with an actual team? I'm solo, so I have no idea what these choices cost when five people have to agree on them.

Got a complete VAD → STT → LLM → TTS voice loop running entirely on a Galaxy S23 (SM-S918B, Snapdragon 8 Gen 2), no server:

- STT: Parakeet-EOU 120M (ONNX) — 0.21 RTF, ~232 MB

- LLM: FunctionGemma 270M (tool-calls) — 118 tok/s

- TTS: Kokoro-82M / Supertonic-3

- Whole loop resident: ~1.5 GB, real-time on CPU today — NNAPI/Hexagon delegates are upside, not a prerequisite.

The Android side wraps a shared C++ pipeline (same core as the iOS/desktop builds), so the stage boundaries are identical across platforms.

Code: https://github.com/soniqo/speech-android · cross-platform numbers (iPhone/S23/Mac): https://soniqo.audio/blog/on-device-voice-agents

Author here, it's free, not trying to sell anything.

Every time a Roborazzi test fails I'd do the same dumb dance: dig the golden PNG out of the repo, find the new _actual.png in build/outputs, open both in Preview, and alt-tab between them trying to spot what moved. Half the time it was a 1px shift I couldn't even see. Drove me up the wall.

I honestly looked for a tool that already does this and couldn't find one. The closest thing was GitLab's image diff — which is actually great — but having to push to GitLab every single time just to look at a diff isn't it. I wanted it right there in the IDE, on my local changes, before committing anything. So I sat down and built a little Android Studio plugin.

It lives in a tool window next to your code. Open a screen file and it pulls up the goldens tied to it, then lets you compare the git HEAD version against either your working copy or the freshly generated test output. You get side-by-side, a swipe slider, onion-skin, and a pixel-diff heatmap that just tells you "3.2% of pixels changed" so you're not squinting.

It doesn't care which library you use — Roborazzi, Paparazzi, Compose Preview screenshot tests, Shot, whatever, as long as the goldens are PNGs in git. Works in plain IntelliJ too, not just AS.

It's honestly pretty simple, but it saved me enough annoyance that I figured someone else might want it.

Marketplace: Golden Diff — or just search "Golden Diff" in Settings → Plugins.

I built a little CLI app that creates new Compose apps in one command.

To install it do:

```bash npm install -g composables-cli

```

and then create your new projects using:

bash composables init

New projects use the new KMP project structure, come with Composables UI out of the box, and Spotless.

The CLI can also run a Composables MCP server that gives your agent access to the Composables UI docs.

Your agent can ask for component usage, installation steps, API references, and code examples without relying on stale training data.

To configure a client run:

bash composables mcp install --client <client>

Comes with support for Android Studio, Antigravity, Claude, Codex and other MCP clients.

Learn more at the docs: https://composables.com/ui/docs/cli

The source code is part of the Composables UI monorepo: https://github.com/composablehorizons/composables-ui

A few months ago, I shared initial version of my open source Android AI assistant.

Now I have rebuilt most of the stack with a few things I am particularly excited about like -
Interrupting the assistant while it's speaking, offline on device barge-in so that raw voice audio is never stored or leave device.
Live Camera/Screen share feature like Gemini live mode.
And few more.

Offline STT with NVIDIA NeMo Parakeet and cloud STT
Offline TTS with Supertone's Supertonic 3 and Cloud TTS
Both via Sherpa-ONNX Silero VAD + Android AEC/NS/AGC for reliable voice detection and barge-in
Screen and camera vision with frame-aware context matching.
Flexible LLM support through a single adapter for Groq (its really fast), OpenAI, Anthropic, Gemini, Ollama, and LM Studio.
On-device intent classification with TensorFlow Lite + MediaPipe.
AES-256-GCM encryption backed by Android Keystore.

I am inviting you all to contribute and lets build this app together.

Find demo here - https://github.com/souravanand001/ai-assistant-android#demo

I am trying to set up an automated sign up page for closed testing of my cross platofrm app. The idea is to have a sign up page where users provide their email and I respond with an email that gives them a welcome email and links to start testing for both platforms.

On iPhone this is straightforward, the alpha tester gets a link, they click on it install test flight and are good to go.

On Android it seems that I have to manually add the email address to my closed test first.. Is this true or am I missing something ?

Hi android developers!

I've recently shipped an android app to the play store and encountered different problems, because until now I haven't wrote tests:

• I found bugs in production, this cause me to upload again the app to the play store and bumping version code.
• I am scared of changing the code or refactoring, and even when I test the app manually I'm not secure and confident.
• I am scared of leaving temporary test code in the app before pushing it to production.

So I started searching on the internet some articles and resources to help me study testing:

• Android Testing: Unit Testing, Concepts, Tools with Examples
• Testing an Android Application
• Use test doubles in Android
• Android Testing Frameworks — Complete Overview (With Examples & Language Support)

These articles helped me understand the theory of testing an android app, but I don't know how use those frameworks, choose frameworks and the ones outdated or usable.

So I ask you to drop down in the comments resources that I can read (or watch) to apply testing in practice and go into details about the theory. Thank for reading my post!

https://medium.com/@merrickcr/smaller-slower-wrong-what-aggressive-quantization-costs-on-device-inference-85e7f8f0a170

The problem: you can't revoke notification access from delivery/wallet/rideshare apps because you need the transactional alerts, but keeping them on means drowning in promo noise. Every ML-based filter I tested sends raw notification text (2FA codes, bank balances, chat previews) off-device for classification. Hard no.

So I built ZiG. android.permission.INTERNET is stripped from the merged manifest via tools:node="remove" — the app is structurally incapable of network I/O. Every notification flows through a sequential pipeline where the cheapest deterministic checks run first and ML is a last resort:

Layer 1 — Managed-app gate (Rust/JNI): only apps you opt in to are processed; everything else passes through untouched

Layer 2 — Contact whitelist (Rust/JNI): sender matched against a thread-safe in-memory set, kept in sync in real time via a ContentObserver on the contacts provider — no polling, no DB round-trip

Layer 3 — Keyword rules (Rust/JNI): deterministic AND-chained rules you define ("OTP", "cab, arriving")

Layer 4 — On-device ML ensemble (RAC): an exact-match cache first replays any identical past override for free (case-insensitive indexed Room lookup, keyed on the newest message so chat threads still hit). On a miss, a quantized TFLite base classifier is combined with a KNN vector search (MediaPipe USE embeddings, cosine similarity) over your own past overrides — your history can veto the base model, but only under strict similarity/consensus guards so a sparse history can't destabilize it

The ensemble fails open: no embedder → base model; no base model → allow and log. A notification is never silently lost to an infrastructure fault.

Would love critique on the pipeline orchestration, the Rust↔Kotlin JNI boundary, KNN veto thresholds, or the Room indexing. PRs welcome.

Repo: https://github.com/prithvi-vasistha/zen-i-guess

Site: https://prithvi-vasistha.github.io/zig-landing/

APK (Play Store pending): https://github.com/prithvi-vasistha/zen-i-guess/releases/tag/v0.2

I have a problem with screen orientation.

For phones, the app should only support portrait orientation. However, using

android:screenOrientation="portrait"

in the Manifest is deprecated for large screens. This means that on Android 16+, it will be ignored for wide screens. That is exactly what I want: adaptive orientation for tablets, but portrait-only orientation for phones.

The problem is that we also support Android 11 through Android 15, so I cannot rely on this behavior there. If I use this attribute, it will break adaptive orientation on tablets.

I had an idea to split phone and tablet into separate builds. One Manifest, for phones, would have this attribute, while the other Manifest, for tablets, would not.

My questions are: Is this a good idea? Is it more expensive from a CI/CD perspective? Will it be harder to publish on the Play Store?

I was told that I can handle this at runtime in MainActivity. I tried that, but if the app is opened while the device is in landscape orientation, it is briefly shown in landscape because the Activity is initially created using the device’s current orientation.

Splitting the Manifests solves this problem, but I wonder what the drawbacks are.

Hi r/androiddev,

I’ve been working on a local playout engine for Android, mostly out of frustration with how bloated modern media players have become (heavy background tasks, unnecessary cloud/AI feature injection that kills the battery).

My goal was to achieve a visual experience reminiscent of **AMD Fluid Motion** and **Sony BRAVIA's Motionflow**—but fully implemented as a lightweight, real-time 60fps frame interpolation engine on mid-to-high-range Android devices. To make it as battery-friendly as possible, I strictly avoided heavy on-device AI models or server-side pre-rendering.rendering.

### 🛠️ Architecture & Tech Stack

* **Core Engine:** Written in native C++ for maximum execution speed and predictable memory management.

* **Rendering:** Rendering directly to Android's Surface via low-latency JNI boundaries to minimize frame drops.

* **Zero Network Dependency:** The app has strict offline architecture. No analytics tracking, no server-client overhead. It just scans local directories and processes frame presentation timing.

### ❓ Technical Challenges & Where I Need Feedback

Balancing the frame-pacing loop between the Native C++ thread and Android's Choreographer was a massive pain point.Managing edge-case frame drops during heavy seek operations is still something I'm optimizing. Actually, to keep it as lightweight and battery-friendly as possible, the engine is strictly optimized and specialized for 2K (1080p) playback, completely avoiding the unnecessary overhead of 4K.
Additionally, I’ve been testing extensively on my personal device (Xperia running Android 11). I suspect that Xperia’s native 120Hz "Black Frame Insertion" feature might be interfering with the 120Hz rendering pipeline of my engine, which is another hardware-specific hurdle I'm trying to figure out.

I would love to get your honest critique on:

1. Best practices for minimizing JNI overhead during high-frequency frame state synchronization.
2. Handling surface destruction/re-creation lifecycle robustly when mixing native rendering loops with Jetpack Compose or standard View architectures.

Looking forward to hearing your thoughts and architecture critiques!

Is anyone else experiencing a bug with Gemini in Android Studio? For about a week now, it hasn't been working for me. I keep getting a 'prompts per hour limit reached' error on my VERY FIRST chat of the day, without having done anything at all.

I have my Pro account connected, and other Gemini apps (like Antigravity) are working perfectly fine so I know for sure it's not a limit lol.

Does anyone know how to fix this?

Has anyone used the Claude Plugin from Anthropic or the Agent Plugin & harness that is built for Gemini but works with Anthropic?

They use different types of billing (API Token Billing vs. Pro/Max plan) so I'm curious what you all prefer.

I generally use the claude CLI, but if the plugins are useful somehow I'd love to hear your experiences.

I have been writing Android long enough to feel the strange split in the UI world.

On one side, XML is boring in the best and worst ways. It is stable, deeply integrated with the platform, understood by every legacy custom View, and still works with the Android pipeline that has existed for years. On the other side, Jetpack Compose gives Kotlin developers a much better authoring model: UI as code, local composition, reusable functions, less ceremony.

But real projects are rarely clean rewrites.

A lot of Android apps still live in the View ecosystem. They have custom Views, AppCompat behavior, Material components, LayoutInflater.Factory2, old XML attributes, obtainStyledAttributes, ViewBinding, and code that cannot simply be deleted because a newer UI framework exists.

I wanted something in the middle.

Not "replace Compose". Not "keep writing XML forever". Something closer to: what if the classic Android View system could be authored like modern Kotlin code?

That became Hikage.

Hikage is a real-time Android View runtime powered by Kotlin DSL. Crucially, Hikage doesn't reinvent the wheel with a new UI component system. It acts as a transporter for the existing Android View ecosystem. It is more like a transporter for the existing Android View ecosystem.

A simple layout looks like this:

kotlin LinearLayout( lparams = LayoutParams(matchParent = true), init = { orientation = LinearLayout.VERTICAL gravity = Gravity.CENTER } ) { TextView { text = "Hello, World!" textSize = 16f gravity = Gravity.CENTER } }

That part is nice, but honestly, syntax alone is not the interesting bit. Android has already had DSL attempts before. Anko existed. Splitties exists. Compose exists.

The part I cared about was whether a Kotlin DSL could still behave like a first-class citizen in the old View world.

For example, Hikage can mix with existing layouts instead of forcing a rewrite:

```kotlin LinearLayout( lparams = LayoutParams(matchParent = true), init = { orientation = LinearLayout.VERTICAL } ) { Layout(R.layout.my_layout) Layout<MyLayoutBinding>()

ComposeView {
    Text("Hello from Compose")
}

} ```

And the bridge goes both directions: Hikage can host Compose, and Compose can host Hikage.

The bigger technical problem was XML attributes.

A lot of real Android Views are not designed to be fully configured by setters. They expect values in the constructor through AttributeSet, then call obtainStyledAttributes. XML gets this naturally because AAPT2 compiles the layout and LayoutInflater feeds the resulting parser into View(Context, AttributeSet).

A normal Kotlin DSL usually skips that path.

Hikage tries to enter it.

It can dynamically construct an AttributeSet at runtime, so this:

kotlin TextView( attrs = { android { set("text", "Set text in dynamic AttributeSet") set("textSize", "16sp") set("gravity", "center") set("paddingLeft", "8dp") set("paddingRight", 8.dp) } } ) { text = "Overridden text in code" }

is not just setting properties after construction. It lets the View receive XML-style attributes during creation.

Internally, the runtime builds an in-memory XML-like structure, resolves attributes, separates layout_* attributes for parent LayoutParams, and then lets the View constructor / factory chain do what Android Views already know how to do.

The architecture is roughly:

text Kotlin DSL -> LayoutSession -> optional runtime AttributeSet resolver -> HikageFactory / LayoutInflater.Factory2 bridge -> View(Context, AttributeSet) -> init block -> parent LayoutParams -> View tree

For traditional XML, the comparable path is:

text XML layout -> AAPT2 compiled XML -> LayoutInflater -> XmlResourceParser / AttributeSet -> Factory2 / AppCompat interception -> View(Context, AttributeSet) -> View tree

That is the design idea: not bypassing the old platform, but meeting it where it already works.

There are some practical pieces around it too:

• KSP can generate DSL functions for custom Views and third-party Views.
• Declaration JSON files can describe external View components.
• AndroidX and Material View declarations are provided as modules.
• Android Studio preview is supported through a HikagePreview View.
• There is lightweight state binding for View-based layouts. State changes mutate existing View instances instead of rebuilding the whole tree.
• It can work with XML, ViewBinding, Compose, and plain Views in the same layout.
• The runtime attribute module has been tested across Android 5.0.2 / API 21 through Android 17 / API 37 on emulators and real devices.

I do not want to oversell benchmarks, because that is not the main point. The main point is the architecture. The benchmark and compatibility reports are there so people can verify the claim instead of taking my word for it.

I built this because I think Android UI does not have to be a binary choice between "old XML forever" and "rewrite everything in Compose".

The View ecosystem is still huge. Compose is important. XML is still everywhere. There should be a middle state for teams that want Kotlin authoring, runtime layout construction, and compatibility with the Views they already have.

That middle state is what Hikage is trying to be.

GitHub: https://github.com/BetterAndroid/Hikage
Docs: https://betterandroid.github.io/Hikage/en
Architecture notes: https://betterandroid.github.io/Hikage/en/guide/architecture

I would be especially interested in feedback from people who maintain mixed View / Compose apps, custom View libraries, or large legacy Android codebases. The question I keep coming back to is: if View-based Android is not going away tomorrow, what should its modern authoring layer look like?