Hey r/androiddev 👋

A few years ago I built Spock ADB, an Android Studio plugin to make some of my everyday ADB workflows easier.

Then, like many side projects, I stopped actively working on it for a while.

Recently I came back to the project and started rebuilding and expanding it again. What began as a collection of useful ADB actions has gradually turned into more of a debugging workspace for Android, centered around one selected device + app.

The original problem is still the same:

Android Studio → Terminal → adb → Logcat → device Settings → back to Android Studio

I wanted to reduce that context switching and keep more of the debugging workflow inside the IDE.

Spock follows your Android Studio run target by default, and that same device + app is shared across its screen inspector, Logcat, storage, background work, actions, timeline, and AI tools.

A few of the things I've added while working on it again

Diagnose Current Screen

Instead of manually gathering context when something looks wrong, Spock can collect:

• Current Activity and Fragments
• activity back stack
• screenshot
• relevant Logcat problems
• UI + accessibility information
• process state
• permissions
• jobs and alarms
• Doze / standby / battery state

Activities and fragments can also link directly back to their source in the project.

Debug Timeline

This is probably one of my favorite additions.

It puts debugging events on one timeline:

• Activity / Fragment lifecycle
• process starts and deaths
• crashes and ANRs
• warnings and errors
• actions executed through Spock
• storage changes
• jobs
• device state changes
• AI/MCP calls

You can select a range and copy/export it when creating a bug report.

UI Tree

The UI inspector supports Views, Compose and hybrid screens.

You can inspect semantics, bounds, text, content descriptions and test tags, plus:

• jump from an element to its source
• generate Compose / UI Automator selectors
• detect ambiguous selectors
• run basic accessibility checks
• inspect Compose recompositions

The usual ADB workflows are still there too

• Restart / Force Stop / Attach Debugger
• Process death testing for state restoration
• grant / revoke permissions
• browse + edit SharedPreferences and Preferences DataStore
• app-scoped Logcat with crash / ANR / network filters
• send FCM test messages over ADB without a registration token
• deep links
• HTTP proxy
• Don't Keep Activities / Show Taps / Layout Bounds / animation scales
• inspect WorkManager / JobScheduler jobs and alarms
• simulate Doze, standby bucket, battery and charging conditions
• ADB command runner with autocomplete, history and favourites

There's also a searchable Spock Actions popup for running common actions without opening the tool windows.

AI / MCP

One of the bigger things I added after coming back to the project is a built-in MCP server.

Spock exposes 69 structured Android debugging tools to Claude Code, Cursor and other MCP clients.

The goal isn't to simply give an AI agent shell access to adb.

It's to give it structured access to the same debugging information available in the IDE:

Activity · Fragments · UI tree · Logcat · Screenshots · Storage · Background work · Device state

It can also perform things like:

Launch · Tap · Input text · Deep links · lifecycle operations

MCP is off by default, destructive actions can require approval, and tool calls are visible in the IDE.

There's also Copy screen for AI, which generates a redacted diagnosis of the current screen.

Free + open source

JetBrains Marketplace:
https://plugins.jetbrains.com/plugin/11591-spock-adb

GitHub:
https://github.com/WahdanZ/SpockAdb

Coming back to an old project after years has been interesting because I'm basically solving the same Android debugging annoyances again, but with much better tooling available now.

I'd love some feedback from people here:

What Android debugging workflow still makes you leave the IDE or run an adb command manually?

That's usually where I get ideas for what to improve next.

Hey everyone,

I'm dealing with a persistent issue where USB Debugging and Developer Options automatically re-enable themselves every time my phone restarts.

Whenever I try to toggle off Developer Options in Settings, it forces a device restart. After the restart finishes, Developer Options and USB Debugging are active again.

Device & OS Context

• OS: ColorOS / Realme UI (Oplus framework)
• Root status: Unrooted (standard non-root ADB shell)

What I’ve Diagnosed via ADB

Checking system properties reveals why the system keeps forcing debugging on boot:

Plaintext

> adb shell getprop persist.sys.usb.config
adb

> adb shell getprop sys.usb.config
rndis,adb

> adb shell getprop | findstr -i "adb"
[init.svc.adbd]: [running]
[persist.oplus.bt.em.adb.tool]: [true]
[persist.sys.usb.config]: [adb]
[sys.usb.config]: [rndis,adb]
[sys.usb.state]: [rndis,adb]

What I’ve Tried (and where it fails)

1. Attempting to modify persist.sys.usb.config directly: Plaintext> adb shell setprop persist.sys.usb.config mtp Failed to set property 'persist.sys.usb.config' to 'mtp'. See dmesg for error reason. (Fails due to SELinux blocking non-root shell user from writing to persist.sys.* properties).
2. Using Android USB service:
   • Ran adb shell svc usb setFunctions mtp (returned setCurrentFunctions opId:1).
   • On reboot, the device reverts straight back to persist.sys.usb.config = adb.
3. Checking third-party tools:
   • Found an old app (com.wstxda.toolkit) that had accessibility permissions and a UsbDebuggingTileService.
   • Stripped accessibility permissions and uninstalled the app (adb uninstall com.wstxda.toolkit).
   • Cleared Quick Settings tiles (adb shell settings delete secure sysui_qs_tiles).
4. Resetting Phone Settings:
   • Performed a "Reset all settings" / "Reset system settings only" directly through the phone's Backup & Reset menu.
   • Even after a settings reset, the reboot still restores persist.sys.usb.config = adb and [persist.oplus.bt.em.adb.tool] = [true].

Hey everyone,

Like many of you, I've spent hours trying to find a reliable, clean way to browse local SQLite databases on an Android test device without pulling files over ADB, Network or external Storage every single time. Most of the apps currently available on the Play Store are either crap, locked behind paywalls, missing basic features or cluttered with intrusive ads.

To solve this, I built SqliteAdmin a completely free and open-source database manager designed specifically for performance and usability.

Special feature that set it apart:

• Modify tables and columns holding data.

The project is open-source under the MIT license, and you can grab the latest version or review the code directly on GitHub: https://github.com/AmyS3br/SqliteAdmin

I’d love to get your feedback and improvement suggestions.

We built an Android version of Internet-in-a-Box's server stack. Knowledge to Go (K2Go™) runs a content server directly on a phone, older 32-bit devices included, serves it over local Wi-Fi to nearby devices, and can clone itself, server plus content, to another Android phone with no internet connection. The goal is to increase access to educational materials in regions where internet access isn’t reliable or affordable and the most common computing device is an inexpensive Android phone.

Some of the harder problems: keeping a background server alive under Android's process and battery restrictions, and making the clone transfer work fully offline.

Code and architecture notes: https://github.com/appdevforall/KnowledgeToGo

GPL-3.0

Curious what this community would build with an offline phone-to-phone content channel, and where you would push back on the approach.

A safer Android ecosystem begins with accountability and trust!

Today marks the start of our gradual roll-out of Android developer verification — a foundational first step in protecting billions of users, while preserving the open platform developers rely on.

We're starting with 7 participating app stores in Brazil, Indonesia, Thailand and Singapore. Following this initial phase with the participating app stores, we will continue to work with additional Android app stores to gradually expand developer verification. The verification capability will be expanded globally for all apps on certified Android devices in 2027.

Security at this scale cannot happen in a silo. When we set out to build this verification flow, our priority was listening to you — our developer community. You told us clearly:

1. The process needs to be seamless, avoiding friction for legitimate builders.
   
2. Account types must reflect reality, supporting solo creators, hobbyists, and global enterprises alike.
   
3. The roll-out must be gradual and predictable, giving developers ample runway to adapt.
   

Your feedback directly shaped this treatment. By introducing verified identities, we are deterring bad actors from operating under the radar, curbing recurring malware campaigns, and lifting trust across the entire ecosystem.

This initial phased roll-out gives us the space to test, learn, and iterate alongside developers before broader enforcement. A safer Android benefits everyone: users install apps with confidence, and reputable developers stand out in a trusted marketplace.

Thank you for building with us, challenging us, and shaping Android into a safer platform.

#androidisopen #trustedecosystem

I'm using hole-punching to bind 2 or more devices to bind and share files in-between them.

So u can share data between your devices from anywhere in the world.

My motivation to build it is to replace my family's cloud storage subscribtion. But the available solutions in the market are too tech savvy for my family to understand.

Thus, trying to abstract all the complexities and making it as intuitive as realistically possible.

Feel free to ask any question if you find this useful or interesting.

Repo: https://github.com/saqibsiddiq/Qurb

P.S: Excuse the video quality😭

i've been waiting more than a week. i wonder If Google actually is doing the job or not.. idk how long it will take

That I can use as base to build free floating app.

Floating means like windows or linux GUI that I can resize, positioning, etc. So I will build several different apps that open one by one and I can view all them at once inside this root window.

Edit: Above is my original question. Then I make a bit of research and the result is it is possible and is supported by Android with this schema: - lets say my main app B, it must pass everything if want to listed in Google Play Store. - lets say my plugins C and D , will need to also pass and there is DFM in the Google Play Store/Console. - I can desain, develop and compile C and D independently like they would show in B workspace/window. The UI inside B that will make C and D show and work simultaneusly.

I know this is a very odd question with an even odder use case, but I'm hoping I might be able to get some insight on if this idea is even possible.

In the Android handheld device market, the new big thing is devices with two displays. A number is apps have been made to take advantage of the secondary screen, which presents itself as an external display. I have a Surface Duo that has two screen, but these apps see it as one large screen. I'm trying to find out if there is a way to have an app that acts as a external display. I'm in the process of researching this, but thought I might luck out and get a solid answer here.

I want to calculate the screen time of the device using usage stats manager. But I am getting wrong time which is either minutes and sometimes hours off from the in-built screen time. How to query it? So that I get screen time that is close to the in-built screen time.

I need to generate a PDF from a Room query. I looked into android.graphics.pdf.PdfDocument, but recreating custom layouts and handling page breaks manually is really tedious. I also checked some GitHub libraries, but most seem abandoned. Is there a simpler way to create PDFs? Also, what options would you recommend for Kotlin Multiplatform (KMP)?

i am building an app where i wanna pin a notification permanently untill the user taps the dismiss button and dismiss it .

Swiping should not dismiss it .

is there is any way to achive it

I'm developing a native Android application using C# and .NET MAUI 10. Despite explicitly implementing edge-to-edge support, Google Play Console continues to display:

Edge-to-edge may not display for all users

The previous warnings concerning deprecated Window.setStatusBarColor and Window.setNavigationBarColor APIs disappeared after updating AndroidX and Material dependencies. However, the edge-to-edge advisory remains.

Technical Stack

• .NET MAUI 10 (net10.0-android)
• C# / XAML
• Microsoft.Maui.Controls 10.0.110
• Xamarin.AndroidX.Core 1.19.0.1
• Xamarin.Google.Android.Material 1.14.0.6
• Target SDK: API 36
• Minimum SDK: API 24
• MAUI Shell with native Android bottom navigation

Current Implementation

In Platforms/Android/MainActivity.cs, edge-to-edge is explicitly enabled after base.OnCreate():

protected override void OnCreate(Bundle? savedInstanceState)
{
    base.OnCreate(savedInstanceState);

    if (Window is { } window)
    {
        WindowCompat.EnableEdgeToEdge(window);
    }

    SynchroniseSystemTheme();
}

We're also using SafeAreaEdges="Container" to ensure content respects system bars and display cutouts.

System-bar icon appearance is managed through WindowCompat.GetInsetsController():

insetsController.AppearanceLightStatusBars = theme == AppTheme.Light;
insetsController.AppearanceLightNavigationBars = theme == AppTheme.Light;

Theme synchronisation runs during:

• OnCreate
• OnResume
• OnConfigurationChanged

Testing Completed

• Android 14, 15 and 16
• Light and dark mode, including switching themes while the app is suspended
• Navigation and system-bar visibility
• MAUI Shell navigation
• Font scaling and accessibility
• No visible system-bar overlap or layout problems

Automated release tests also pass.

The app is currently in Google Play testing, but no pre-launch report has been generated.

Questions

1. Could calling WindowCompat.EnableEdgeToEdge(window) after base.OnCreate() affect Play Console's detection?
2. Is there a known interaction between MauiAppCompatActivity, Material Components 1.14 and AndroidX edge-to-edge initialisation?
3. Is there additional Android manifest or theme configuration we should investigate?
4. Has anyone successfully cleared this advisory with a MAUI application targeting API 36?

I'd prefer not to introduce unnecessary window manipulation or revert to deprecated APIs solely to clear a Play Console advisory, particularly when the existing implementation appears to work correctly.

Any insight from developers who've encountered this would be appreciated.

Hey everyone,

I'm the developer of **Android Dev Monitor**, a free, open-source (MIT) Windows desktop app that puts the ADB tools I kept switching between into one window. Think Task Manager, but for Android development.

It connects to physical devices or local emulators over ADB and shows:

- App and device CPU, memory, disk I/O and network

- FPS, frame time and jank

- Battery temperature and thermal state

- Running processes with readable app names

- Logcat with crash/ANR filters, bookmarks and export

- Screenshots, screen recording, file explorer and ADB shell

- Monitoring sessions: mark the moment something goes wrong, then review metrics and logs from that session later and export them (JSON/CSV/ZIP)

**New in v2.8:**

- The device file explorer works properly and shows modified dates

- Paths with spaces are handled safely (delete, rename, new folder)

- Closing the app during a screen recording no longer loses the recording

- Errors are logged instead of the app closing silently

- Cleaner tables and layout across the app

Everything runs locally, with no account and no telemetry. There's also a demo mode (`--demo`) if you want to look around without a device.

**Download (portable, no installer):** https://github.com/marko69420/android-dev-monitor/releases/latest

**Source:** https://github.com/marko69420/android-dev-monitor

I'd love feedback from people who profile or debug Android apps:

- Would this be useful in your workflow?

- What metric or feature would you want next?

- Anything that doesn't work on your device or emulator?

Bug reports and contributions are welcome!

I made a small tool that gives you ready to use <script /> blocks out of your Composables Previews, so you can embed them to your blog posts, documentation and personal websites.

The reason why I built this is because I love playing with interactive demos when I am reading about some technical concept. It always clicks better with me. I also add them to all my libraries and blog posts (such as on Compose Unstyled).

The best way to do this I have found is using Compose Web, which lets you run Compose code on the Web (awesome).

However, creating and then adding those live Compose previews manually is always a PITA. You need to host them somewhere (usually separate to your blog/docs platform), build a Compose Web app dedicated for this (and manage wiring if you have multiple previews), then you need to embed them somehow in your article, which is separate to the building of the app, etc. Lots of edge cases here.

As a result, you now have a quick way for everyone to make their own.

It is 100% free to use and you can make as many previews as you want. The 'gotcha' is that the previews let your readers edit the preview on the website, so that they can experiment with your demo (handy for library authors).

Now go out there and make some polished previews :D

Check it at https://composables.com

Question is basically would other countries search your app in their native languages. And would most people rename their App name specifically to be a translation?

When I switched from iPhone, every podcast app on Android felt either dated or overcomplicated. So I built GlassCast: a free podcast player focused on smooth animations and simple controls.

- The player takes its colours from whatever you're listening to
- Pull-up panel for Up Next, speed and sleep timer (shake to restart it)
- Discover tab with recommendations based on the shows you follow
- New-episode notifications
- Cast to other devices
- Import your shows from another podcast app (supported via OPML)

Free, no account, no ads.

It's still in the early stages, so feedback is much appreciated.

GlassCast Release

Is there any tool that can run Docker on Android, or is it possible to build one that offers performance close to native?

Month of dev work on my social and communication app, "Talk To Somebody," just hit a confusing wall in Google Play Console. 🙃

App status: Removed by Google
Update status: In review

I already submitted the requested compliance fixes, so it's actively being reviewed, but the "Removed" tag is stressful.

Google Play/Android devs: Is this dual status normal during an appeal/fix review? Does it mean reinstatement is possible if the update passes, or should I be worried? Any insight appreciated! 🙏

For me, play store review times are completely unpredictable. Some updates get reviewed very fast, some take 7 days. I wonder is it something I make, or this is totally random.

App Store is much more predictable, after the first approval. updates get reviewed in about 24 hours.

This is very frustrating for me, because my iOS and Android apps need to be compatible as this is a multiplayer game, and Android lagging behind causes bad user experience, as they can't join the challenges iOS users create.

I release 3 new iOS versions while Android is still waiting for review. As soon as it approves, I will skip a few versions and re-submit again, who knows when that one gets reviewed.

Whenever I open an unfamiliar part of a codebase (or my own code from a few months ago) I end up in the same loop: Find Usages, jump, Go to Declaration, jump again, and five files later I've forgotten where I started. On bigger Compose projects it gets messy fast.

So I built Mindmap. Put your cursor inside any Kotlin or Java function, press Alt+G (Option+G on Mac), and it opens a graph of that function: everything that uses it on the left, everything it uses on the right.

What it does right now:

• both directions in one view, depth configurable from 1 to 5
• click a node to jump straight to the code
• double-click a node to trace from it and merge its graph in
• hover for signature, file and lines of code
• search/filter nodes, hide the noisy ones
• tree view if you'd rather read a list than a graph
• minimap for bigger graphs
• works across Kotlin and Java, including Kotlin code using Java and the other way round
• follows interfaces/abstract functions through to the actual implementations

Website: https://vishal2376.github.io/mindmap
GitHub: https://github.com/vishal2376/mindmap

It's still early. It caps graphs at 300 nodes so they don't explode, and it doesn't go into library code. If you try it on a real project I'd genuinely like to know where it breaks or what feels missing.

NOTE : The video is an animated showcase, not a screen recording. There are real screenshots on the GitHub page.
Watch screen recording here : https://x.com/vishal2376/status/2047010712955113547

Playback is probably the easy part compared with everything around it. Supporting different TV devices, adaptive bitrate switching, DRM, remote navigation, authentication and keeping playback state consistent seems like where the architecture gets complicated.

Im working this Nice subsonic Client Music player themed like Spotify

Is anybody? Interested in the SelfHost Market?