June 16. Google ships Android 17, and I read the announcement the way developers do: half skimming, half squinting for the part that breaks my weekend. I'm Artem Garazha, I build Android apps from Ukraine, and my current obsession is a little retro-styled app called PinUp, which I present on my YouTube channel and which I mostly ship to the Play Store by myself, without a team. So when Google said "mandatory resizability" and "an intelligence system" in the same breath, I was paying attention.
The part nobody can skip: your app has to resize now
If you target API level 37 on a device with sw > 600dp, Android 17 removes the opt-out. The system starts ignoring things we've all been hiding behind for years: screenOrientation, setRequestedOrientation(), resizeableActivity="false", aspect ratio constraints. Legacy manifest attributes. Gone. Games get an exemption based on Play category, but a "lifestyle" or "tools" app does not.
I had one of those legacy attributes. One. It was in a screen that honestly nobody uses on a tablet, which is exactly why it survived. The lesson is not about the attribute. It's that large screens are no longer a separate world you plan for in Q4. Google puts 580 million of them in the hands of users, and there's a new Googlebooks line (ChromeOS on the Android stack) coming, so the large-screen population keeps growing. Your app has to handle any window size, respect the user's posture, and support free-form windowing. If you're using Jetpack Compose, you're mostly in luck. That's the quiet win of the Compose era: declarative layouts don't care about orientation.
The new multitasking stuff is more fun. App Bubbles: long-press any app icon in the launcher and it becomes a floating bubble. On tablets there's a Bubble Bar in the taskbar to dock them. Desktop mode gets interactive PiP, where the pinned window is still fully clickable, not a read-only video tile. I already tested the long-press on a Pixel. It works. It's a bit much, honestly, but my app survived it, which is more than I can say for my old layout with a hard-coded 16:9 video block.
The part I actually care about: AppFunctions and Android MCP
Here's the headline for people who've been watching what happened in the web world. Android 17 expands AppFunctions, a platform API with a matching Jetpack library, that lets your app expose its capabilities as orchestratable "tools" for Android MCP, the on-device equivalent of the Model Context Protocol. An AI agent, in practice Gemini, can discover your app's functions and execute them with access to local state. No webview. No scraping. A real API call into your app.
The way you add it is almost insulting in how easy it is. You annotate a class and write KDoc:
class NoteFunctions(private val noteRepository: NoteRepository) {
/**
* Adds a new note to the app.
*
* @param title The title of the note.
* @param content The note's content.
*/
@AppFunction(isDescribedByKDoc = true)
suspend fun createNote(
appFunctionContext: AppFunctionContext,
title: String,
content: String
): Note = noteRepository.createNote(title, content)
}
That's it. The Jetpack library is in alpha, there's an "agent skill" that analyzes your app's workflows and generates the code for you, plus ADB commands and a test agent app to simulate the integration. Gemini hookup is in private preview right now, but you can start preparing. There's an early access program at goo.gle/eap-af if you want in.
Why does this matter to me specifically? My app is small, personal, aesthetic. The kind of app an agent could plausibly drive: "add this to my board", "show me the last thing I saved". Before AppFunctions, the only way for an assistant to touch my app was for the user to open it and tap through. Now the app can say "here is a verb" to the system. I've been prototyping one function against the test agent app, and the moment the simulated agent called it and my UI updated, it felt like the app got a door.
One caveat I'd take seriously: your KDoc becomes your API documentation for a machine reader. If your docs are garbage, your function is garbage. I rewrote a few comments that were written for human colleagues, and that's a weird new job description: documenting for LLMs.
What I did this weekend
Practical list, for the solo developer:
- Bump targetSdk to 37 in a branch. Run the app on a tablet, rotate it, drag it to a corner in free-form mode. You'll find your layout sins fast.
- Grep for the legacy orientation attributes. If you find them, ask whether the screen actually needs the lock.
- Pick one or two user workflows in your app and write them down as functions with parameters. That's your AppFunctions shortlist.
- If your app is public and has reviews, check Play Console: the resizability requirement is enforced per API level, so it's a deadline, not a suggestion.
I also took the chance to re-shoot the presentation video, because the new multitasking features make for better demo footage than my previous "here is my app on a phone" setup.
Where this leaves me
Android 17 is a big release, and Google's framing of it as an "intelligence system" is doing a lot of work in that sentence. What I can actually see is more modest and more useful: the platform is preparing a stable way for agents to call into apps, and it's forcing the large-screen question to the front of your backlog. Neither of those is a problem for an app built in Compose with a sane layout strategy. Both are problems for the app you keep telling yourself you'll refactor in the spring.
I'll write up the AppFunctions prototype when it's further along, probably with the demo video. If you want to see where the app is headed, my Instagram posts the build progress between releases.
Top comments (0)