I was originally working on one of my projects for this upcoming winter break and I wanted to use the camera of my phone and then I found how insufferable it is to setup cameraX

so I did what any sane developer will do and I spent 4 days building a library that allows me to call the camera in just one line

now I just call camera.open { picture -> //whatever I want to do with it }

also the other reason I did it is because any other library I found out there didn't really make it as simple as I wanted it to be

do you guys think this is something android should of have done from the beginning? I do understand that some people many need to tweak with camerax more but most of the time many apps just need the picture

if you guys want to check it out into detail this is the repo. PLEASE LET ME KNOW IF SOMETHING IS BROKEN OR YOUR HONEST THOUGH!! https://github.com/al3j4ndrolm/FacilisCam

Hi all, just wanted to share a quick update that I've released a new version of HDCharts.

Demo: https://charts.hdcode.dev/demo/3.0.0/
Documentation: https://charts.hdcode.dev

Would appreciate any feedback!

Update: Dev Challenge

While working on the library, I wanted to make the documentation easy to read and visually appealing. Since the charts support animations, I wanted to use GIFs in the documentation, but creating them manually was time-consuming.

My initial idea was to use an iframe and some bridges to render web content directly in the docs, but I decided against it because it didn't feel like the right approach and seemed a bit hacky.

Instead, I created a dedicated plugin to generate GIFs, which I can use both locally and in CI: https://github.com/HDCharts/charts-gif-recorder

Hi all, I'm the developer of Swipewalk. Checked with the mods before posting, they said a dev tool like this is fine.

It scans an app running on an emulator or USB phone. It runs Google's Accessibility Test Framework together with its own checks and reports WCAG 2.2 issues with screenshots and who each issue affects. It works on Views, Compose and cross-platform apps since it reads the accessibility tree, not your code.

The part I find most useful: it can turn on TalkBack, move through each focusable control and record what TalkBack actually says, next to what it predicted. That catches things like a button TalkBack just calls "Button" or reads out a resource id. It can also rescan at large font size, in dark/light and in the other orientation, and tells you when a control that was there at normal size can't be reached anymore at large text.

0.6 improved how it names Views and Compose controls (a field labelled with android:labelFor, a button named by several child texts). I checked that on my own native sample apps, not on third party apps yet. If you point it at your source folder it tries to find the likely source line for a finding. I measured that on seven real open source apps (four Android), and the testing page lists the misses.

Things to know:

- It changes phone settings while it checks (text size, TalkBack, dark mode, rotation) and puts them back after. Use a test device. TalkBack is silent for the few seconds it's capturing.

- Runs from a Mac (desktop app or command line). Tested on a Pixel 4a with Android 13 and the Android 16 emulator. Haven't tried it from Windows or Linux yet.

- Automated checks only find part of the issues, so you still need manual testing with TalkBack. It doesn't certify anything.

Free to use, runs locally, no telemetry. I built it with a lot of help from AI coding assistants, I review and test what ships.

What it found and missed in testing: https://github.com/swipewalk/swipewalk/blob/main/docs/testing.md

Downloads (there's a sample apk if you just want to see a report): https://github.com/swipewalk/swipewalk/releases

Would really like to hear what's wrong or missing if you try it on your app.

Hi everyone I am preparing for android interview recently with 3+ yrs of exp, I am good with topics of basic fundamentals

But struggle with topics involving scalability like

1. let's us say you have an api that gets called 1 time per second, and your user is having low internet or unstable conditions how to handle this

2)how do you handle battery optimization for your app

After deep diving with Claude and discussion i understand the approach

So can you list down some practical questions like this you faced or would ask in a sde 2 interview

Thank You

Most device recovery workflows break down in real-world theft scenarios because they assume an active data uplink. When a phone is stolen, the opportunistic flow is predictable: immediate Airplane Mode toggle, data cut, and fast attempts to access banking or mobile money apps before the user reaches an external computer.

I wanted to design an open-source architecture that operates entirely offline at the telephony layer without requiring Play Services cloud connectivity during a critical event.

I’ve open-sourced the implementation under MIT:

GitHub: https://github.com/kingenious0/trackd

I would appreciate engineering feedback on the native Android architecture and how people are handling edge cases around modern OEM background policies.

Native Android Architectural Decisions

Telephony Layer Interception (SMS_RECEIVED vs abortBroadcast) Because cellular data is typically the first vector cut, the daemon relies on direct SMS commands (#LOCATE#PIN, #SIREN#PIN, #STOLEN#PIN). An ordered BroadcastReceiver with maximum priority (999) intercepts the raw PDU. If authenticated against a local salted hash in Android Keystore, the receiver invokes abortBroadcast() to prevent notification chime alerts or cluttering the default SMS inbox. Outgoing coordinates are returned via SmsManager directly to a designated recovery number.

App Lockdown & Decoy ANRs via AccessibilityService A lightweight AccessibilityService monitors window state change events. When the daemon is switched to an elevated threat state, foreground attempts to launch targeted package names (banking, system settings, mobile money) immediately dispatch a system dialog overlay spoofing a standard Application Not Responding (ANR) crash and redirect to the default launcher.

Cold GPS Fixes Without Network Assistance Standard GPS locks rely on SUPL/A-GPS cellular assistance data to achieve fast fixes. When offline, FusedLocationProviderClient with high accuracy must fall back purely to standalone GNSS satellite tracking, which leads to extended time-to-first-fix. To mitigate this, a last-gasp cache is preserved, while the receiver holds a partial WakeLock to allow the GNSS chip to cycle satellite ephemeris data before dispatching the response.

Questions & Edge Cases for the Community

OEM Background Killers (MIUI/HyperOS & OneUI): Even with a declared Foreground Service and battery optimization bypasses, HyperOS still frequently terminates background jobs after an hour of deep doze unless the user manually grants vendor-specific Autostart and background pop-up toggles. Has anyone discovered cleaner intent deep-links or standard workarounds to keep telephony listeners alive across aggressive Asian vendor skins?

Dual-SIM Default Carrier Selection: On Android 12+ dual-SIM devices, SmsManager.getDefault() occasionally throws exceptions when dispatching background SMS if the user hasn't configured a default SIM for outgoing messages. How are you currently resolving the active SubscriptionInfo safely when sending system alerts?

Android 14/15 Broadcast Restrictions: With increasing platform restrictions on non-default SMS apps handling SMS_RECEIVED, what are your preferred patterns for zero-data telemetry failover?

Source code is available on the GitHub repository above. Any code reviews, PRs, or architecture critiques are welcome!

Hey everyone!

I've been working on an Android document scanner, and I decided to take a different approach: instead of relying on existing pretrained TFLite models, I'm training my own model for document detection.

My current model is named "doc_edge_fp_32.tflite", and training is still ongoing.

Here's what I'm working toward:

- Custom AI model: Training on thousands of generated document samples mixed with real photographs.

- Dual predictions: Document segmentation masks and corner coordinates.

- Offline processing: The goal is to run document detection directly on Android without requiring a server.

- Accurate scanning: Reliable document boundaries, perspective correction, and better results on challenging backgrounds.

- Real-world performance: Generalizing beyond synthetic images to receipts, sheets of paper, and book pages.

I'm still training and evaluating the model, so I don't want to claim it's production-ready yet. My next priority is testing it on unseen real-world images and optimizing inference for mobile devices.

I'm curious about a few things:

1. For document detection, would you recommend a shared backbone with separate segmentation and corner-regression heads?

2. What techniques have worked best for bridging the gap between synthetic training data and real camera images?

3. What metrics would you prioritize before deploying a model like this on Android?

I'd love to hear from people who have worked on computer vision, document scanning, segmentation, or on-device ML.

This is a learning project I'm putting serious effort into, and I'm excited to see how far I can take it!

Since it's easier to make apps now with AI vibe coding, does it affect your revenue?

I just followed this tutorial about android app links: https://developer.android.com/codelabs/android-app-links-introduction.

The solution https://github.com/android/deep-links/tree/main/deep-links-introduction/solution seems to be just a regular app with a regular data store and a regular navigation graph that doesn't really behave any differently when it comes to handling these links. Now I'm not sure what the point of them is.

Has anyone here worked with Android app links before? I'm struggling to understand what the point of this tutorial is.