Android enthusiast · app builder · automation obsessive
I make software for the little problems that shouldn't be so difficult. If a task takes too many taps, breaks after an update, or needs a clunky workaround, I'll probably try building something better.
| Project | The idea | Where it's at |
|---|---|---|
| 📁 MyFilesMyChoice | My files. My choice. Bring back control over Android file-picking, with a sane system-picker fallback. | 🛠️ Rebuilding and testing system-wide integration |
| 🛡️ Sus'AF | A KernelSU/SUSFS module with an audit-driven WebUI, explainable configuration changes, backups and rollback. | 🧪 Active development / prerelease |
| 🛒 all'gone! | A real-time shared-list app because getting groceries shouldn't require a committee meeting. Open the app ↗ | 🌱 Live app, still improving |
A note on releases: I distinguish working prototypes from tested releases. “In development” actually means in development.
Some projects are original builds; others are forks used to test ideas, investigate compatibility, and contribute improvements.
| Public repository | Area |
|---|---|
| LSP-IrenaX | Android hooking and framework experiments |
| GKI_KernelSU_SUSFS | GKI kernels, KernelSU and SUSFS |
| HMA-OSS-Lsposed | App visibility and privacy-related tooling |
Credit for upstream projects belongs to their original maintainers; check the individual repositories for attribution and licenses.
Android Kotlin Java Python TypeScript React Vite Bash GitHub Actions Firebase Vercel KernelSU LSPosed
Things I gravitate toward: Android internals, useful web apps, automation pipelines, practical UI/UX, and occasional hardware / 3D-printing side quests.
- Android: reliable file-picker interception and an escape hatch when an app isn't compatible.
- Root tooling: safer module automation, clear diagnostics, and changes you can roll back.
- Web: smoother shared lists and less annoying shopping workflows.
- Everything else: small utilities that eliminate repetitive work.
💭 A few rules I build by
1. Fewer steps is a feature.
2. A good fallback beats a perfect demo.
3. Test the actual end-to-end workflow.
4. Don't call a half-built feature finished.
5. Keep it understandable, reversible, and useful.
If it feels like a workaround, there's probably another project coming.
Useful > flashy. Working > almost working.
Some experiments stay private until they're ready to share. Everything linked above is intentionally public-facing.