DEV Community: Weavri

Shipping a signed Android APK as a solo dev (and the WiFi app it was for)

Weavri — Mon, 19 Oct 2026 11:46:16 +0000

I shipped a small Android app this week and I want to talk about the other half of building it: making the release artifact something a stranger can actually trust.

WiFi Beacon (WiFi 哨兵) is a tiny utility: you pick a Wi-Fi network, and every time you open an app you've flagged as distracting while connected to that network, it throws a full-screen wall in front of it. It's the digital equivalent of putting the snacks on a shelf you can't reach.

It's not exciting. That's the point — it's the kind of app that either works quietly or doesn't get used at all.

What it actually does

Pick a Wi-Fi SSID (the one you work on)
Pick the apps you don't want to open there
A foreground-service detector (AccessibilityService) notices the app coming to the foreground
A full-screen warning covers it: "You're on . You opened . Go back?"

The logic is small. Most of the value is in getting the details right:

Getting the current foreground app without root. ActivityManager.getRunningAppProcesses() is basically useless post-Android 5. The reliable route is an AccessibilityService watching TYPE_WINDOW_STATE_CHANGED. It costs you a scary permission dialog, so the app has to justify it clearly in one sentence.

Android 12 broke SSID reads. WifiManager.getConnectionInfo() no longer hands you the SSID the way it used to — you now need ACCESS_FINE_LOCATION (and on 13+, NEARBY_WIFI_DEVICES) or the SSID comes back as <unknown ssid>. That's the single most common bug in this category of app.

I wrote both of those up in detail before building this:

The part I'd been skipping for years: shipping a signed, verifiable release

I've shipped debug APKs by hand for years. This time I did it properly, and the friction was all in places I didn't expect (no Android Studio involved — just JDK 17, the Android SDK, and Gradle on a headless Linux box):

assembleRelease with no signing config produces an unsigned APK, and Gradle will happily give you a success message for it. The signing config has to be conditioned on a properties file that exists outside version control.
services.gradle.org being unreachable doesn't fail loudly — the wrapper just sits there. The fix is getting the distribution into the wrapper cache under the right hash, or pointing at a mirror.
Verify what you shipped, not what you think you shipped:

apksigner verify --print-certs app/build/outputs/apk/release/app-release.apk
shasum -a 256 app-release.apk

I wrote that flow up too: No Android Studio? Build APKs in GitHub Actions and verify them on real hardware

The result

Same app, four ways in — no paywall in front of the code:

Source: github.com/weavrikx/wifiwarn — MIT, build it yourself, do whatever you want with it
Signed APK (4.5 MB): releases/latest — built and verified, SHA-256 published alongside it
Landing page: weavrikx.github.io
The paid version, if you just don't want to compile: ¥9.9 (about $1.40) for the ready APK + a setup guide, or a ¥99+ white-label build (your app name, icon, warning copy, preset rules)

Why "open source + a $1.40 paid build" instead of one or the other

I went back and forth on this and landed here: the code being MIT isn't a loss leader, it's the honest position — I'd rather someone fork it than bounce off a paywall. The paid tier sells not having to build it, which is a real thing people pay for. Nobody who wants to git clone was ever going to be a customer, and pretending otherwise mostly just annoys developers.

If you've fought the Android 12 SSID permission mess, or you've ever shipped an unsigned APK and only found out later, I'd like to hear how you handled it.

No Android Studio? Build APKs in GitHub Actions and verify them on real hardware

Weavri — Mon, 19 Oct 2026 10:14:58 +0000

You can ship Android APKs without ever installing Android Studio. This is the loop I use: CI builds the APK, I pull it back, I verify it on a real device. Total cost: $0.

Why not build locally

Android Studio is huge and GUI-dependent — painful on a headless Linux box
A cloud runner gives you a clean, reproducible build environment; switching machines changes nothing
For a small personal project, the free CI minutes are more than enough

1. The GitHub Actions workflow

.github/workflows/build.yml:

name: build
on: [push, workflow_dispatch]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with:
          distribution: temurin
          java-version: '17'
      - name: Build debug APK
        run: ./gradlew assembleDebug
      - uses: actions/upload-artifact@v4
        with:
          name: apk
          path: app/build/outputs/apk/debug/*.apk

Push and you get an artifact. You can also trigger it manually from the Actions tab.

2. Get the APK back onto your machine

gh run download <run-id> -n apk

3. Verify on a real device (the step people skip)

"Build succeeded" ≠ "it runs." Install over adb and actually exercise it:

adb install -r wifiwarn-debug.apk
adb shell dumpsys accessibility | grep -i enabled   # is the service actually up?
adb logcat -s WarnService                           # watch the runtime log

I accept builds on a Huawei device running Android 14: install, enable the accessibility service, connect to the target WiFi, open the target app, and confirm all three warning channels fire.

This is the part that matters. A green CI badge proves the compiler was happy. It proves nothing about behaviour on a real OEM ROM with a real battery optimiser and a real accessibility implementation.

4. The gotchas

./gradlew: Permission denied — commit the wrapper and chmod +x gradlew
JDK version: AGP 8.x needs JDK 17, not the runner's default 11
Artifacts expire after 90 days by default — promote real releases to a GitHub Release

The takeaway

Cloud build + real-device acceptance is a cheap way to make every artifact you hand over carry evidence, not just a promise. The build environment is disposable; the verification is not.

Project: github.com/weavrikx/wifiwarn

I'm Weavri, an indie Android developer. Cloud builds, real-device testing, reproducible artifacts.

Android 12+ returns for WiFi SSID — the permission fix

Weavri — Mon, 19 Oct 2026 10:07:52 +0000

You ship a WiFi feature. Users report it "doesn't work". You log the SSID and find this:

<unknown ssid>

Your code is fine. Your manifest has ACCESS_WIFI_STATE. And yet. Welcome to the Android 12 permission model.

The symptom

val wifiManager = context.getSystemService(Context.WIFI_SERVICE) as WifiManager
val ssid = wifiManager.connectionInfo?.ssid   // "<unknown ssid>"

No crash. No exception. Just silent garbage — which is the worst kind of failure.

The root cause

Starting with Android 12 (API 31), reading the WiFi SSID requires a runtime permission. Declaring it in the manifest is not enough.

You have two options:

ACCESS_FINE_LOCATION — the legacy route, still works, still prompts
NEARBY_WIFI_DEVICES — new in Android 13 (API 33), and the semantically correct one for "I just want to see WiFi devices, not track location"

If the permission is declared but not granted, the API returns <unknown ssid> instead of throwing.

Working code

fun getCurrentSsid(context: Context): String? {
    val wifiManager = context.applicationContext
        .getSystemService(Context.WIFI_SERVICE) as WifiManager
    val info = wifiManager.connectionInfo ?: return null
    return info.ssid?.removeSurrounding("\"")
}

And the runtime request, version-gated:

if (Build.VERSION.SDK_INT >= 33) {
    requestPermission(Manifest.permission.NEARBY_WIFI_DEVICES)
} else if (Build.VERSION.SDK_INT >= 31) {
    requestPermission(Manifest.permission.ACCESS_FINE_LOCATION)
}

Three traps I actually hit

1. The quote trap. connectionInfo.ssid comes back quoted — literally "HomeWiFi" with the double quotes included. Always removeSurrounding("\"") before comparing, or your SSID match will never fire.

2. On newer OEM builds, NEARBY_WIFI_DEVICES is a hard dependency. Tested on a Huawei device running Android 14: without the nearby-devices permission you get <unknown ssid> even with location granted. Don't assume location alone is enough on API 33+.

3. Never treat <unknown ssid> as a valid value. Explicitly null-check and reject the sentinel. Otherwise you'll end up with a saved rule named <unknown ssid> that silently matches nothing.

Where I used this

WiFi Beacon (wifiwarn) matches a combination: the currently connected WiFi SSID and the foreground app. When both match, it warns you.

Source: github.com/weavrikx/wifiwarn — issues and stars welcome.

I'm Weavri, an indie Android developer. Everything I ship is tested on real hardware (Android 14) and reproducible.

Getting the Current Foreground App on Android Without Root (AccessibilityService)

Weavri — Mon, 19 Oct 2026 10:05:57 +0000

If you need to know which app the user is looking at right now — for a focus timer, a parental-control tool, an anti-distraction app — you hit the same wall at step one: how do you get the current foreground app without root?

I shipped a tool that does exactly this, and this post is the part I wish someone had written for me.

The obvious options, and why they all fail

Approach	Verdict
`ActivityManager.getRunningTasks()`	Deprecated since Android 5.0. Returns only your own task.
`getRunningAppProcesses()`	Returns only your own process (Android 8+).
`UsageStatsManager` ("Usage access")	Works, but latency is up to ~10 minutes. Useless for real-time.
`AccessibilityService`	`TYPE_WINDOW_STATE_CHANGED` fires the instant the window changes. ✅

AccessibilityService is the only real-time, no-root option.

The price: the user must enable the service manually (Settings → Accessibility). There is no legitimate way to toggle it programmatically, and you shouldn't try — that's a Play-policy landmine.

Minimal working implementation

class WarnService : AccessibilityService() {

    override fun onAccessibilityEvent(event: AccessibilityEvent?) {
        if (event?.eventType != AccessibilityEvent.TYPE_WINDOW_STATE_CHANGED) return

        val pkg = event.packageName?.toString() ?: return
        if (pkg == packageName) return   // ignore our own windows

        checkAndWarn(pkg)
    }

    override fun onInterrupt() {}
}

The manifest — every attribute matters here:

<service
    android:name=".WarnService"
    android:exported="true"
    android:permission="android.permission.BIND_ACCESSIBILITY_SERVICE">
    <intent-filter>
        <action android:name="android.accessibilityservice.AccessibilityService" />
    </intent-filter>
    <meta-data
        android:name="android.accessibilityservice"
        android:resource="@xml/accessibility_config" />
</service>

And res/xml/accessibility_config.xml:

<accessibility-service xmlns:android="http://schemas.android.com/apk/res/android"
    android:accessibilityEventTypes="typeWindowStateChanged"
    android:accessibilityFeedbackType="feedbackGeneric"
    android:notificationTimeout="100" />

Four pitfalls that actually bit me

Use TYPE_WINDOW_STATE_CHANGED, not TYPE_WINDOW_CONTENT_CHANGED. The latter fires on every content update — your battery graph will look like a ski slope.
Guard against self-triggering. When your own warning overlay appears, that's also a window-state change. Filter out your own package name or you get an infinite loop.
Throttle. A 30-second cooldown after each warning. Without it, a user who is genuinely distracted gets spammed and uninstalls.
Don't try to block. Blocking an app launch requires root. "Detect + notify" is the correct no-root design — and it keeps you on the right side of Play policy.

What I built with it

WiFi Beacon (wifiwarn): you configure a target WiFi SSID + a target app. When the phone is connected to that WiFi and the app opens, it fires a sound, a notification, and a full-screen overlay.

Use cases: a parent policing games on the home WiFi; or self-discipline when you're supposed to be working on the office WiFi.

The whole thing runs locally — no cloud, no data collection, Android 8–15.

Source: github.com/weavrikx/wifiwarn — stars and issues are welcome.

I'm Weavri, an indie Android developer. I test on real hardware (Android 14) and ship reproducible builds.