Every Android Liquid Glass library I could find targets Jetpack Compose. My app is still on

XML layouts — like most shipping Android apps — so none of them were usable without a

UI-framework migration.

So I built one as a plain FrameLayout subclass. Add it to your layout, put your content

inside, done.

- Real SDF refraction — edge compression ring driven by a live rounded-rect SDF, follows

corner radius in real time

- Physical dispersion — per-channel refraction along the surface normal

- Sensor-driven specular — highlight moves as you tilt the device

- Single-pass AGSL pipeline on API 33+, C++/NEON classic pipeline down to API 24

Screenshots are from a physical device (API 36), not mockups. MIT, on JitPack.

https://github.com/QWEA0/Liquid-Glass-Android

Happy to answer questions about the AGSL lens math — getting the SDF-driven compression

ring to track corner radius without a per-frame displacement map took a while.

I’ve been waiting a week to get an update published and this will be at least another week after that 🙃

Apparently calling me an idiot does not violate Google Play comment posting policy.. good to know.

Is this normal or are you normally successful with such requests?

I'm hitting a strange issue that's specific to a single project. When I bump the Android Gradle Plugin from an older version to any 9.x release (tested with 9.3.0), Android Studio's editor and lint start flagging a huge number of "Unresolved reference" errors (100+ problems shown in the inspection gutter) across multiple Kotlin files - including files that use generated ViewBinding/DataBinding classes, Hilt-injected classes, and Room entities.

The odd part: the actual Gradle build succeeds with no compile errors at all. The app builds, installs, and runs fine on a device/emulator. It really looks like an IDE indexing/false-positive problem rather than a real compilation problem, but it makes the editor basically unusable (error highlighting everywhere, autocomplete acting up).

I've only ever seen this in this specific project , other projects on the same machine, same Android Studio version, updated to AGP 9.x work completely fine. So it feels tied to something in this project's module setup rather than a general AGP 9 bug.

Relevant setup (module-level build.gradle):

• compileSdk = 37, targetSdk = 37, minSdk = 23
• Kotlin Android plugin, kotlin-parcelize
• KSP (not kapt) for annotation processing — Room, Hilt, and a kotlinx-metadata-jvm KSP dependency
• Dagger Hilt (2.60.1)
• Room (2.8.4) via KSP
• Navigation Safe Args (Kotlin)
• viewBinding enabled (buildFeatures { viewBinding true })
• Google Services / Firebase Crashlytics / Analytics / Messaging plugins
• Secrets Gradle plugin (Maps platform)
• coreLibraryDesugaringEnabled true
• Java/Kotlin target set to 11 (sourceCompatibility/targetCompatibility 11, jvmTarget.set(JvmTarget.JVM_11))
• multiDexEnabled true

Top-level build.gradle:

gradle

buildscript {
    ext {
        version_gradle = '9.3.0'
    }
    dependencies {
        classpath "com.android.tools.build:gradle:$version_gradle"
        classpath 'androidx.navigation:navigation-safe-args-gradle-plugin:2.9.8'
        classpath 'com.google.dagger:hilt-android-gradle-plugin:2.60.1'
        classpath "com.google.android.libraries.mapsplatform.secrets-gradle-plugin:secrets-gradle-plugin:2.0.1"
        classpath 'com.google.gms:google-services:4.5.0'
        classpath 'com.google.firebase:firebase-crashlytics-gradle:3.0.7'
    }
}

plugins {
    id 'com.android.application' version '9.3.0' apply false
    id 'com.android.library' version '9.3.0' apply false
    id 'org.jetbrains.kotlin.android' version "2.4.10" apply false
    id 'com.google.devtools.ksp' version '2.3.2' apply false
}

tasks.register('clean', Delete) {
    delete rootProject.buildDir
}

Has anyone else run into unresolved-reference/false-positive IDE errors specifically after moving to AGP 9.x, especially in a project mixing ViewBinding + Hilt + Room + KSP + Safe Args? Would appreciate any pointers on what in this combination might be confusing the IDE's resolution/indexing even though the actual Gradle compilation is clean

I got the standard Play Console warnings on my TWA (a Bubblewrap-generated Trusted Web Activity):

1. Must target Android 16 (API 36) by Aug 31, 2026

2. Must use Google Play Billing Library 8.0.0+ by Aug 31, 2026

   The target SDK one is trivial - one line in the app build.gradle (targetSdkVersion 36), compiles fine.

   The billing one is the problem, and it seems to be on Google's side, not mine. My TWA doesn't call the Billing Library directly. It uses the Digital Goods API + PaymentRequest (https://play.google.com/billing), which is bridged by com.google.androidbrowserhelper:billing. That bridge is what actually embeds the Play Billing Library.

   I checked the source, and the bridge is still on Billing 7:

   - Latest billing release is billing-1.1.0 (June 25, 2025), which explicitly says "BillingClient library updated to 7.1.1".

   - The main-branch version catalog (gradle/libs.versions.toml) still declares billing = "7.1.1".

   So Google is warning every TWA to move to Billing 8, but Google's own TWA billing library hasn't been updated to 8 (it's been sitting on 7.1.1 for over a year).

   Force-overriding com.android.billingclient:billing:8.x on top of the old bridge looks risky - Billing 8 removed deprecated APIs the old bridge relies on, and I've seen reports of queryProductDetails() silently breaking after the v8 jump on native/Flutter setups. Not something I want to ship blind on a live payment flow.

   Questions for anyone in the same boat:

   - Is there any known timeline for android-browser-helper billing to move to Billing 8?

   - Has anyone successfully forced Billing 8 into a TWA and confirmed purchases still work end to end?

   - Are you just requesting the extension to Nov 1, 2026 and waiting?

   For now I've requested the extension in Play Console (reason: "waiting on a new SDK version from an SDK provider"). Curious what everyone else is doing.

I have an Android app, which is just a WebView of a website. That website sends notifications to users. Those notifications should be sent to the Android app as a badge on the app's home screen launcher icon when the app is closed. The users need to have an account to receive those notifications because they are user-specific.

Does anybody have an idea how I can do that? AI suggests Firebase Cloud Messaging. Thank you in advance.

I've been submitting my new app listing for review and It keeps getting rejected even though I can access it from many different locations, but the google app reviewer keeps sending a cloudflare block page and rejecting the submission.

I checked the Cloudflare setting and it seems that it's blocking bot users from foreign countries, but this is a non-negotiable due to botters. Is there any way to get around this issue?

Has anyone else run into this before? All and any advice is welcome.

I am really curious about how difficult is it to make money off your own apps ? it's literally like a dream scenario for me because I freaking hate my part time job . If my project could actually help cover just my rent and utilities/food I would happily quit that job and just completely focus on University and building my resume.

Hi everyone,

I wanted to share some technical takeaways and challenges from a native Android project I've been working on (AnvilAI — a fully offline, native LLM runner).

1. Handling C++ NDK & Vulkan Bindings with Compose: Bridging the C++ NDK inference layer with Vulkan GPU acceleration to Jetpack Compose required a clean asynchronous pipeline. I used Kotlin Coroutines and Flow to stream token outputs from the native side directly into the Compose UI without blocking the main thread or causing frame drops.

2. Encrypted Local Storage with SQLCipher: Since all model execution happens locally, keeping local chat histories encrypted on-device was a priority. Integrating SQLCipher alongside Room ensured encrypted persistent storage with minimal performance overhead during read/write operations.

3. Architecture & Tech Stack:

• UI: Jetpack Compose (Material 3)
• Core Engine: C++ NDK layer leveraging Vulkan for GPU acceleration
• Database: SQLCipher
• DI: Hilt

I’d love to discuss how others are approaching native C++ integration with Jetpack Compose or handling heavy GPU workloads on modern Android devices (Snapdragon vs Dimensity chips).

Source Code:https://github.com/denizaydogan1902/AnvilAI

Feedback on the architecture and PRs are always welcome!

I just open-sourced serve-avd, a small tool that puts your emulator in a browser tab:

npx serve-avd → http://localhost:3200

It boots your AVD if nothing's running, streams the screen as smooth H.264, and forwards full interaction — touch/drag/fling, scroll wheel, keyboard typing, Back/Home/Recents, volume, power, theme toggle, screenshots. Tunnel the port and the emulator is usable from anywhere.

How it works (no root, no on-device agent, no app instrumentation — plain Node + adb):

• adb exec-out screenrecord --output-format=h264 → re-framed into length-prefixed AVCC chunks → decoded in-browser by WebCodecs onto a canvas
• screenrecord only emits frames when the screen changes and dies every 3 minutes, so the server keeps a GOP cache (decoder config + last keyframe + deltas since) and replays it to new viewers — instant paint on connect, invisible restarts
• Input runs over one persistent adb shell per device to skip the ~100 ms per-command handshake; live drags use input motionevent
• MJPEG fallback for browsers without WebCodecs

There's also a CLI aimed at scripting and AI agents — tap, gesture, type, rotate, screenshot, ax (uiautomator hierarchy as JSON), event-log — plus a Connect-style middleware so you can mount the whole thing inside your Metro/Express dev server at /.emu.

Fun problems along the way:

• screenrecord silently letterboxes into 720x1280 when the display exceeds the encoder's limits — you must always pass --size
• settings put system user_rotation doesn't reliably rotate modern Android; wm user-rotation lock does
• On Play-store images, SELinux blocks writing to /dev/input even though the shell user is in the input group — so two-finger pinch only works on rootable images. If anyone knows a better way, I'm all ears.

It's a port of Evan Bacon's serve-sim (which does this for iOS simulators) — same interface and wire protocol, rebuilt on what adb provides.

GitHub: https://github.com/hsandhu/serve-avd
npm: https://www.npmjs.com/package/serve-avd

Apache-2.0. First release — feedback and PRs welcome, and tell me what breaks.

I have a PWA wrapped with Bubblewrap (TWA) on a personal developer

account. I've now been rejected twice for production access after

completing closed testing. Both times Google marked the first two

requirements as complete — closed testing release published, and 12+

testers opted in — and only asked me to keep testing for 14 more days.

A paid testing service is telling me the cause is the TWA architecture

itself: that because the content runs through Chrome, Google can't

attribute enough engagement to the app. They recommend temporarily

shipping a native WebView wrapper under the same package name, passing

review, and switching back afterwards. I'm not comfortable doing that —

it looks like exactly the kind of bait-and-switch that gets accounts

terminated — and I can't find any Google documentation supporting the

claim.

So I'd like to hear from actual developers:

1. Has anyone here passed production access with a TWA, without

   switching architecture? (Personal account, post-Nov-2023, so the

   12 testers / 14 days requirement applied.)

2. If you were rejected repeatedly with a TWA, what finally worked?

3. Does anyone have a source suggesting Google measures tester

   engagement differently for TWAs?

For what it's worth, my own server logs show my testers went inactive

4-9 days before the review date, which seems like a much simpler

explanation than architecture. But I'd rather hear from people who've

been through it than guess.

Thanks.