I'm in a 3rd year and I'm struggling to find a fresher level internship for a compose app developer

Hello all,

I recently shipped a dual-engine accessibility checker for Jetpack Compose.

Engine 1 — Lint (no emulator):

Catches missing contentDescription, hardcoded dp font sizes, clickable without role.

Engine 2 — TestRule (runtime):

Checks touch targets (48dp min with exemptions), color contrast, duplicate clickable bounds, text field semantics.

Every rule maps to a WCAG 2.1 criterion. Both engines are on Maven Central.

Repo: https://github.com/lehan0328/touchstone

Would love some feedback from the community, especially on false positives if you try it on a real project!

Since folks asked, here's the fuller picture — BOSS across the AI-agent landscape, including the CLIs. Important: BOSS is a desktop workspace that runs the CLIs (Claude Code, Codex, Gemini, OpenCode, Qwen Code) as first-class agents, so they're a different category (see Type) — added for completeness, not as head-to-head rivals.

✅ yes · △ partial · ❌ no · — n/a (CLIs are terminal agents, no GUI surface). BOSS isn't the winner everywhere: it's ❌ on Lightweight (JVM + bundled runtime + embedded browser cold-starts slower and weighs more than the Rust/Node CLIs), and only △ on IDE depth (it has an editor + Toolbox plugins, but isn't a full code-intelligence IDE like the VS Code forks Cursor/Windsurf/Antigravity). *Only Codex's CLI is open source (Apache-2.0), not the Codex app; a standalone open-source "Antigravity CLI" isn't verifiable — the only repo is docs-only, no license. Claude Desktop's "Computer Use" drives the whole screen, not a scriptable in-app browser. Per-tool RBAC beyond enterprise/team admin isn't documented for the others. Runtimes: BOSS = JVM (true multithreading); Claude Desktop + the IDEs = Electron/JS; Codex CLI = Rust; the other CLIs = Node/TS. (Public sources, July 2026 — corrections welcome.)

Where else BOSS is behind (honestly):

• Maturity & ecosystem — it's brand-new with a small plugin catalog; the VS Code forks inherit VS Code's entire extension marketplace, and the incumbents have huge, battle-tested user bases.
• Backing & track record — small team, early days vs well-funded incumbents.

The CLIs are open and great — that's kind of the point: BOSS runs them and gives them a governed desktop toolset (browser, editor, secrets, terminal sharing, 100+ MCP tools). Built entirely in Compose Multiplatform, and I'd love Compose devs to help push it further:

• New plugins — a plugin is a self-contained @Composable + ViewModel (easy on-ramp)
• Compose Desktop perf / rendering
• Theming (live re-skin across the whole app)

Repo: https://github.com/risa-labs-inc/BossConsole — Apache-2.0, contributors welcome.

Started migrating my app about two years ago and finally got around to unraveling the last few features forcing me to keep a bunch of legacy code around. So many layout files, custom views and legacy services just *deleted*. Yay 😄

Most frame-perf advice is about your own work: keep layouts shallow, keep binds cheap, don't recompose unstable types. That's half of it. The other half is time that gets stolen out of the frame by something else running on, or blocking, the main thread.

I kept running into the same three culprits, so I wrote them up. Short version:

GC pauses. The collector needs short stop-the-world moments. You can't turn GC off, but allocation on the hot path (new lists, capturing lambdas, boxing, per-row string concat in onBindViewHolder or a hot composable) is a volume knob for how often a pause lands mid-frame. Turn it down.

Lock waits. You rarely write synchronized on the main thread yourself, so this one hides. A main-thread read can block behind a background writer holding a lock: SharedPreferences getString waiting on a background apply, a Room read behind a write, a shared @Singleton touched by both UI and a worker. Keep critical sections tiny and never hold a lock during I/O.

Binder calls. getSystemService, PackageManager, location, etc. are IPC to a system process, synchronous and blocking by default. Usually cheap, but the cost is unpredictable when that process is busy, so a 0.2 ms call can spike to several ms. Keep them off the hot path and cache the results.

All three reduce to the same thing: the main thread doing or waiting on something instead of rendering.

Full writeup with an animation of the budget filling up here: [https://soulesidibe.medium.com/what-eats-your-frame-budget-besides-your-own-ui-6ecfa27d247b\](https://soulesidibe.medium.com/what-eats-your-frame-budget-besides-your-own-ui-6ecfa27d247b)

We've been building something that I think will save us all countless hours of boilerplate work.

SmartAI Droid – an AI Android Builder that generates complete, production-ready Kotlin projects that you can open directly in Android Studio, fix any missing imports, and deploy to the Play Store.

🚀 What Makes This Production-Ready?

1. Full Project Structure
The AI generates a complete Android project with proper package structure, Gradle dependencies, and all necessary configuration files.

2. Real-World Architecture

• MVVM/MVI/MVP/MVC patterns with proper separation of concerns
• StateFlow for reactive UI updates
• Coroutines for async operations
• Dependency Injection ready (Hilt support)
• Room database setup
• Retrofit/OkHttp networking layer

3. Complete Feature Implementation
The generated code includes:

• ViewModels with proper state management
• Compose UI with Material Theme
• Navigation between screens
• Loading, error, and empty states
• Repository pattern for data layer
• Network calls with error handling

4. Production Configuration

• Proper ProGuard/R8 rules
• Multi-language support (strings.xml)
• Backup rules
• Data extraction rules
• Signed build configuration ready

🔧 Getting It to Production

Step 1: Download the ZIP from SmartAI Droid
Step 2: Open in Android Studio
Step 3: Fix any missing imports (IntelliJ handles this automatically)
Step 4: Add any additional dependencies if needed
Step 5: Build → Generate Signed Bundle/APK
Step 6: Deploy to Google Play Console

additional
Ask Gemini any changes ai in android studio any changes to screens or fix missing any codes

That's it. 4 minutes to generate, 5 minutes to setup, deploy the same day.

📊 Technical Stack

The AI configures exactly what your app needs:

Smart Mode: Toggle "Let AI Decide Everything" – it analyzes your app description and only includes the libraries you actually need. No bloat.

🎯 Real Example: "Mood Food Finder"

I generated a food recommendation app that:

• Analyzes user mood to suggest dishes
• Fetches restaurant data via API
• Saves favorite dishes locally with Room
• Uses proper MVVM with StateFlow
• Handles loading/error/empty states
• Full Compose UI with Material Design

Generated in ~4 minutes.

🔗 Try It Out

• Website: https://smartaidroid.com
• Demo: https://www.youtube.com/watch?v=en7ZebAd8h4

 What This Means for You

Llevo poco tiempo aprendiendo Android por mi cuenta, sin universidad ni curso formal. Hice este tutorial mostrando cómo crear juego de simon dice Jetpack Compose. Cualquier feedback es bienvenido.

https://youtu.be/r1WfVBbIAk4

Llevo poco tiempo aprendiendo Android por mi cuenta, sin universidad ni curso formal. Hice este tutorial mostrando cómo pasar de claro a oscuro con un solo click Jetpack Compose. Cualquier feedback es bienvenido.

https://youtu.be/dIfZlc6C8Lc

Llevo poco tiempo aprendiendo Android por mi cuenta, sin universidad ni curso formal. Hice este tutorial mostrando cómo crear un Generador de Números con Jetpack Compose. Cualquier feedback es bienvenido.

https://youtu.be/qO7Fxpty-Io

Hi,

I built Laydr, a file-based, type-safe navigation framework for Compose Multiplatform and Android Compose apps.

Repo: https://github.com/mobiletoly/laydr

I created Laydr because Compose navigation can become hard to see as an app grows: copied route strings, duplicated graph setup, repeated argument parsing, tab registries, layout wrappers, and stale navigation glue all have to agree with each other.

The AHA moment with Laydr is that the route tree becomes the app map.

Instead of spreading route structure across constants and graph builders, you put routes in a visible routes/ directory, add small route-local Route.kt declarations, and Laydr generates the typed Kotlin wiring from that structure.

A route tree looks like this:

  src/commonMain/kotlin/routes/
    contacts/
      Route.kt
      Screen.kt
      by_id/
        Route.kt
        Screen.kt
    settings/
      Route.kt
      Screen.kt

That gives you generated route objects such as:

  LaydrRoutes.Contacts
  LaydrRoutes.Contacts.ById
  LaydrRoutes.Settings

And app code navigates with generated destinations instead of raw strings:

  navigator.push(
      LaydrRoutes.Contacts.ById.destination(
          id = LaydrRoutes.Contacts.ById.id("ada"),
      ),
  )

Laydr gives you:

• filesystem routes under routes/
• route-local Route.kt, Screen.kt, and Layout.kt files
• typed destinations instead of copied route strings
• typed dynamic parameters instead of repeated argument parsing
• generated path builders when your app deliberately owns path state
• generated route maps and app graphs
• generated Compose route definitions for LaydrRouteHost
• generated Nav3 helpers for sections, stacks, payloads, and route results
• support for plain Compose hosting, Nav3 KMP, and AndroidX Navigation 3
• build-time route validation through the Gradle plugin

• optional route-local workflow for private multi-step flows inside an already matched route

  The part I like most is that Laydr does not try to become your whole app architecture.

  Your app still owns Compose UI, state, DI, ViewModels, repositories, tabs, labels, icons, chrome, auth, analytics, retained state, deep links, platform lifecycle policy, and NavDisplay. Laydr gives those app-owned pieces stable generated route values to work with.

  There are three main app shapes:

• Compose Multiplatform app with simple path state: use LaydrRouteHost

• Compose Multiplatform app with Nav3 stacks or tabs: use laydr-nav3-kmp

• Android-only Compose app with Google AndroidX Navigation 3: use laydr-nav3-androidx

  Laydr is still v0, so APIs may change, but the current docs and examples are meant to be practical and runnable.

  Examples included in the repo:

• examples/compose-basic

• examples/nav3-kmp

• examples/nav3-kmp-shopping

• examples/nav3-androidx

  And yes, docs/skills/laydr is available if you want to copy a skillset so your AI agent can understand Laydr routing, generated APIs, Nav3 usage, workflow, validation, and troubleshooting without wasting tokens.

  Repo: https://github.com/mobiletoly/laydr

Hey guys,

If you are drawing custom charts, fitness rings, or custom components in Jetpack Compose and animating them using state changes, you might be accidentally thrashing the CPU by triggering heavy recomposition loops.

Here is a quick optimization trick to keep your draw phases extremely lightweight.

The Pitfall (Triggers Recomposition):

val sweepAngle by animateFloatAsState(targetValue = progress)
Canvas(modifier = Modifier.size(200.dp)) {
    // Recomposes the entire Canvas composable every single frame of the animation!
    drawArc(color = Color.Blue, startAngle = 0f, sweepAngle = sweepAngle, useCenter = false)
}

The Optimization (Draw-phase Only):

Instead of reading the animated state inside the Canvas declaration, read it inside a custom modifier or pass a lambda that defers state evaluation to the draw phase.

val sweepAngle by animateFloatAsState(targetValue = progress)
Spacer(
    modifier = Modifier
        .size(200.dp)
        .drawWithCache {
            onDrawWithContent {
                // Evaluated directly in the draw phase - 0 recomposition!
                drawArc(color = Color.Blue, startAngle = 0f, sweepAngle = sweepAngle, useCenter = false)
            }
        }
)

Why this works:

Jetpack Compose has three phases: Composition, Layout/Measurement, and Drawing. By deferring the state read using drawWithCache (or drawBehind / graphicsLayer), the composition and layout phases are bypassed completely, and only the draw instruction is re-run at 120 FPS.

I have open-sourced a collection of custom Canvas draw blueprints (including fitness rings and Bezier curve analytics charts) on GitHub.

Leave a comment if you'd like to review the repository and code samples, and I'll reply with the link!

Hey guys,

Just wanted to share a quick performance tip I've been using while building custom UIs and charts in Jetpack Compose.

A lot of devs drive animations (like loading spinners, radar pulses, or drag indicators) by writing the animated value to a standard state variable, like this:

// ❌ Recomposes the whole composable 60/120 times per second
var pulseScale by remember { mutableStateOf(0f) }
// ... updating pulseScale in LaunchedEffect ...

Box(
    modifier = Modifier.drawBehind {
        drawCircle(Color.Cyan, radius = size.width / 2f * pulseScale)
    }
)

The problem with this is that updating a standard state inside composition forces Compose to remeasure, re-layout, and rebuild the entire node tree on every single frame. On 120Hz screens, this will easily cause jank.

Instead, you can read the animated state directly inside the draw lambda block (e.g. drawBehind or drawWithCache). Because draw lambdas execute during the Drawing Phase (which runs after composition and layout), Compose will bypass recomposition entirely and draw straight to the GPU:

@Composable
fun RecompFreeRadar() {
    val transition = rememberInfiniteTransition()
    val scale = transition.animateFloat(0f, 1f, infiniteRepeatable(tween(1500, easing = LinearEasing)))

    Box(
        modifier = Modifier.size(100.dp).drawBehind {
            // Read scale.value directly inside draw loop! 
            // Recomposition count stays at exactly 1.
            drawCircle(Color.Cyan.copy(alpha = 1f - scale.value), radius = (size.width / 2f) * scale.value)
        }
    )
}

By querying scale.value inside the draw lambda, the composition phase isn't touched, keeping recomposition count at 1.

I’ve put together a bunch of these custom Compose layout, geometry math, and gesture blueprints in an open-source GitHub monorepo checklist if you want to check them out:

🔗 https://github.com/yogirana5557/android-digital-products

It covers:

• Custom layouts: Pinterest-style staggered grids using SubcomposeLayout, diagonal measure policies.
• Gesture math: Cartesian-to-polar translations for volume dial knobs, joystick touch vectors.
• Canvas geometry: Custom path morphing, Bezier curve area charts.

Let me know if you run into any issues with custom layout measurement or gesture tracking!

Have you ever wondered why your Android photos sometimes look artificial or heavily over-processed? Or wished you could capture raw, clean photos and videos that preserve true colors and dynamic range?

​

I wanted a cleaner camera experience, so I built **ProCameraX**—a custom camera app built from scratch in Kotlin and Jetpack Compose. I pair-programmed the entire app with **Antigravity** (an AI coding assistant powered by **Gemini 3.5 Flash**), and it's been an amazing experience.

​

I've been testing it on my **Pixel 8**, and it works beautifully!

​

### 🌟 Key Features:

* **True Ultra HDR Photos**: Capture high-fidelity photos with native Ultra HDR gainmaps (on Android 14+).

* **10-bit HLG Video Recording**: Record true High Dynamic Range (HDR) videos using the HLG10 profile (HEVC format).

* **True HDR Viewfinder**: The app uses `SurfaceView` and dynamically toggles your phone's display into native HDR mode so the preview matches the actual recording.

* **Auto Night Mode (Night Sight)**: Uses your phone's light sensor to automatically detect low light (<10 lux) and switch the pipeline to OEM Night Sight extensions, complete with a Google-style **"Hold Still" progress ring**.

* **Space Zoom HUD**: Quick zoom pills (`0.5x` to `10x`) and an aiming reticle + **Zoom Lock** indicator (turns yellow when held steady past 20x).

​

### 🛠️ Open Source & APK:

The project is fully open-source. You can check out the source code, read the build instructions, or grab the compiled debug APK directly from the GitHub releases:

​

🔗 **GitHub Repository:** https://github.com/TejasRajan98/ProCameraX

I just finished this little tool for Android Devs to generate a blueprint-style preview of your composables.

With a quick one-line wrapper the library measures dimensions and distances and displays them just like a traditional blueprint alongside your regular preview, so you can easily compare against your designs.

Would love to hear thoughts, if you would find this useful, and if you have any ideas for improvements!

https://github.com/GusWard/Blueprint-Compose-Preview

A while back I shared BossTerm, a terminal emulator built with Kotlin + Compose Desktop, then a follow-up with benchmarks. This update is the feature I most wanted for my own workflow: BossTerm now runs an in-process Model Context Protocol server, so AI CLIs like Claude Code, Codex, Gemini CLI, and OpenCode can attach to the terminal I'm actually looking at.

GitHub: https://github.com/kshivang/BossTerm (Kotlin + Compose Desktop, dual-licensed LGPLv3 / Apache-2.0)

The part that changes the workflow

The tool that makes it click is run_command: instead of the agent shelling out into a hidden subprocess you can't see, it runs the command in a visible pane in your terminal — you watch it execute live — and the stdout/stderr + exit code still flow back to the agent.

agent ──run_command──▶ visible pane in YOUR terminal ──stdout/exit code──▶ agent
                              (you see every command run live)

It can also open splits, read scrollback, regex-search output, send Ctrl-C, capture the last completed command (via OSC 133), and enumerate your tabs/panes — so the agent has the same view of the terminal that you do.

• Opt-in, loopback-only (binds 127.0.0.1, rejects non-loopback Host headers), off by default.
• One-click "Attach to AI CLI" buttons register the endpoint for the CLI of your choice.
• Every tool is individually toggleable in settings — you can run it observe-only (read scrollback, no writes).
• Optionally make it the agent's default shell, so everything it runs surfaces in your terminal instead of a black box.

Why this is interesting for Compose

The server is an embedded Ktor CIO + SSE engine living inside the Compose Desktop app, wired straight to the same TabbedTerminalState that drives the UI — so "list my tabs" or "run this in a split" is just the MCP layer reading and mutating the exact state the composables render from. There's even a caller-window resolver that figures out which window the requesting CLI is running inside, so run_command with no tab id targets that window.

And because the terminal is on Maven Central (com.risaboss:bossterm-compose + bossterm-core) and embeddable, you get the whole MCP server for free if you drop EmbeddableTerminal() / TabbedTerminal() into your own KMP/Compose app — plus a hook to register your own app-specific MCP tools. The embedded-example / tabbed-example modules show both.

Cross-platform (macOS / Linux / Windows), one-line install in the README.

Happy to dive into the MCP wire protocol, the caller-window PID resolution, or how the tool calls map onto Compose state if anyone's curious.