Software engineer · Berlin, Germany
Cesar
Valiente
Android at Microsoft — Surface Duo Developer Experience
I build Android apps, and the guidance that helps other people build theirs. For the last few years my work has centred on what happens when a screen stops being one fixed rectangle — foldables, dual-screen, adaptive layout — and on leading the Android@Microsoft community, where the company's Android teams share what they learn.
Before that: architecture and Kotlin, a decade of Android apps, and a move from Madrid to Berlin that never got reversed.
Madrid ✈ Berlin
Still writing Android
- Role
- Software engineer, Surface Duo Developer Experience
- Leads
- The Android@Microsoft internal community
- Focus
- Foldable & adaptive UI, architecture, testing
- Writes
- Kotlin, and Java when the code is old enough
- Ask me
- Foldables, architecture, testing, careers, community
Now building
What I work on
Three things I keep coming back to
Adaptive & foldable UI
Jetpack WindowManager, activity embedding, list-detail, navigation that survives a posture change. Layouts that hold up when the device is a phone, a tablet and a book within the same second.
Architecture in Kotlin
Unidirectional data flow, borrowed from Flux and Redux and made to sit properly on Android's lifecycle. Testing, modularisation and build setups that outlive the demo.
Teaching it back
Codelabs, workshops, conference talks and a weekly stream. Most of what I learn leaves as something someone else can clone, run and take apart.
Selected work
Problems I solved once, then published
Each of these started as something a team of mine needed that week. They are open source, and the two below are the ones other developers have built on most.
Unidirectional data flow for Android
A reference implementation of one-way state on Android in Kotlin: a single source of truth, state moving in one direction, side effects pushed to the edges. It takes the ideas behind Flux and Redux and works out what they mean once you have to survive a configuration change.
Why it exists
Every Android team of that era was rediscovering the same state bugs. I wanted an argument you could run rather than one you had to read — the app is the talk, and the talk is the app.
Slides: Unidirectional data flow on Android using Kotlin ↗
Source ↗
Runtime permissions, the week the rules changed
Android 6.0 moved permissions from install time to runtime and quietly broke a common assumption in every app. This walks the whole new model — the request, the denial, the "never ask again" dead end — and wires it into a real screen rather than a demo activity.
Why it exists
Written in the weeks after the release, when the documentation was thin and everyone was guessing. A decade on, the permission model it explains is still the one Android ships, which is why people keep forking it.
Across the fold
Surface Duo Developer Experience · 2020 → today
Earlier apps & experiments
2013 → 2022
Toolbox
What I reach for
- Languages
- Kotlin first, Java where the code predates it, a little Rust and Swift
- UI
- Jetpack Compose and the View system, WindowManager, Navigation, SlidingPaneLayout
- Architecture
- Unidirectional state, Coroutines and Flow, Room, modularisation
- Build
- Gradle, and Bazel when a repo gets big enough to need it
- Testing
- JUnit, Espresso, instrumented runs across emulator matrices
How I work
Small, runnable, explained
I'd rather answer one question properly than demonstrate ten things at once. Nearly everything I publish is a single app that isolates a single API, small enough to read in an afternoon and run before lunch.
The same habit carries into teams: write the thing down, make it reproducible, hand it to whoever needs it next. That is most of what running a community turns out to be.
Writing, speaking & community
Most of the work leaves as an article or a talk
Foldable development, software architecture, testing, Android, career advice, leadership, community building — these are the subjects I end up talking about most. If you want me at your event, send me a message.
Medium
Years of writing across different publications — architecture, Kotlin, testing, and the occasional piece on how teams actually work.
PublicationMicrosoft Mobile Engineering
How Android gets done inside Microsoft, written by the teams doing it. I help run the community behind it.
Dev blogSurface Duo Blog
Posts on dual-screen and foldable development, usually shipping next to a sample you can clone and run.
Conference talksTalks on video
Recordings from conferences over the years, collected in one playlist.
Live, weeklyTwitch stream
Weekly streams on foldable and dual-screen development, with the back catalogue archived on YouTube.
Free softwareOpen source
Glad to help FLOSS projects that want to support foldable devices and aren't sure where to begin.
In active development
Layer Four
The first blockchain layer built exclusively for mobile.
Layer Four is an execution layer on Solana designed for one device class instead of adapted to it. The premise is simple and slightly stubborn: if the phone is where people actually are, the phone should be a first-class participant in the chain — not a thin client asking a server for permission to see its own state.
The premise
Mobile is treated as an afterthought. It shouldn't be.
Almost every chain in production was designed for hardware that is plugged in, cooled, and connected by fibre. Mobile support arrives later as a wallet — a viewer onto infrastructure running somewhere else. It works, but the phone is a spectator.
Layer Four inverts the constraint. The mobile device is the design target from the first decision onward: what a handset can verify on battery, what fits through a congested radio, what survives a tunnel, and what an operating system will let you keep in a secure enclave.
Why this, why now
Solana already carries a large, genuinely mobile-first audience onchain, and it is the one major chain that has put real effort into the handset. Those users will not be running a validator on a desktop. Building the layer they meet the chain through — and building it for the device they already hold — is a better bet than porting a desktop assumption onto a smaller screen.
Fifteen years of building for Android, applied to a problem where the mobile constraints are the whole problem.
Design constraints
Four rules the implementation has to answer to
These are commitments rather than features. Anything that can't be made to fit inside them doesn't ship.
Verifiable on a handset
A phone should be able to check the chain's claims itself, on battery, without delegating trust to a server it happens to be pointed at.
Budgeted for a mobile radio
Bandwidth and latency are treated as hard budgets, not averages. Proof size and sync cost are design parameters, not consequences.
Keys stay in the enclave
Signing uses the hardware the platform already provides. A key that can be exported is a key that eventually gets exported.
Survives a bad connection
Tunnels, lifts, aeroplane mode, a process the OS killed to save memory. Interruption is the normal case on mobile, so it's handled as one.
Android builds
Download the APK
Signed alpha builds, installed by sideloading. Pick arm64-v8a if you have any phone made in roughly the last eight years; the universal build is the fallback for everything else.
Layer Four — arm64-v8a
Recommended for modern devicesLayer Four — universal
All supported ABIs, larger fileInstalling
Sideloading, in three steps
Download the APK on the device itself, or move it across with adb install
from a machine with the platform tools.
Open it. Android will ask whether your browser or file manager may install unknown
apps — that permission is per-app, under Settings → Apps → Special
access, and worth turning back off afterwards.
Check the SHA-256 against the value published with the release before you trust the
file. sha256sum on the desktop, or any checksum app on the phone.
Read this first
These are alpha builds of software that talks to a blockchain. Run them on a device you can afford to wipe, with keys you can afford to lose, and against test funds only. Sideloading is a permission you are granting to a file you downloaded from the internet — verify the checksum, and be equally sceptical of anyone else offering you a build of this.
Found a bug, or want to be told when the next build lands? Reach me here.
Support
Back the build
Layer Four is being built in the open, on my own time. If it's useful to you and you want to help it keep moving, this is the address.
Donation address
GhJpfjRoBuKApuhjStqyS4Ha7tftgA6uqkLFy9cNf7jj
A Solana address. Send SOL, or any SPL token, on Solana mainnet-beta — check the network before you sign, because a transfer on a chain I can't reach is a transfer nobody can recover.
Sending to this address is a donation, and nothing else. It is not a token purchase: it buys no equity, no share of anything and no claim on the project, and nothing is owed to you in return. Give only if you'd be content having simply given.
Scan to send
Open a mobile wallet and scan. Fitting, for a project whose whole argument is that the phone should be the first-class device.
Verify the first and last four characters against the address on the left before confirming — GhJp and f7jj.