When it comes to engineers addressing questions, you’re bound to get into wonk, wonk and more wonk. A Reddit AMA session in this aspect is verily not consumer-friendly. But we do believe that there is worth in extracting some answers where we can.
Last week, the Android O engineering team took to /r/AndroidDev to answer a few questions about how developers are coping with things like the new Kotlin programming language and certain design rules and libraries being applicable.
Addressing the Android 8.0 dessert name: it seems that will have to wait until “later this summer!” But that hasn’t stopped some staffers from offering their own name suggestions like “Okra Pudding,” “Oak Tree Cookie,” “Android On to P,” “Android Ovaltine,” and “Android Oobleck.”
We’ll boil this down into bullet points, sorted in chronological order of when the issue was first addressed.
- Wondering about dialogue boxes that used to pop up, but don’t anymore? Things such as a progress box are considered “UX anti-pattern” and unfriendly to users.
- Software updates through the Project Treble interface will be native to new devices running Android O, but will also be implemented into AOSP so that older devices can take advantage of it. It will ultimately be up to OEMs, though, to put their updates through the interface.
- Android isn’t too hot on OEM theming. It had enough trouble trying to get Material’s dark theme to work on bundled apps like Calendar, so that’s what you’re seeing it only pop up once in a while. And that’s beyond working with color rules for readability. Still, the team’s aware that app devs including a “dark mode” signal demand and has a work-in-progress based on a Sony product.
- Adaptive Icon shapes will be pushed into the AOSP launcher for apps targeting API level 26. You’re already seeing rounded squares surrounding Google apps if you’re running the Android O beta.
- Expect some more physics-based animations soon.
- Autofilling on Chrome? That relies on Google’s Autofill tool and is active now. WebView — aka a Chrome window opened within Twitter and the like — should have it soon.
- If you have to deal with a laggy Direct Share panel before you share content to your favorite social network, the team’s “actively investigating” a push-based system instead of a wide communication of intent to every possible app to share to.
- Bluetooth audio improvements go beyond the codec — Android Nougat’s active task scheduler caused plenty of data packet delays and jitter. A streamline of the process for Android O should produce a better result.
- Colored navigation bars in line with colored notification bars for apps are a tough ask because of UX issues. Even if it helps with AMOLED burn-in, this may not be the solution we’re after.
- Android is moving away from its blob emoji design in order to better fit in with Unicode’s expanding standards — they feature more personas and bodies.
- Android Wear will get background process limits and notification channels with the ‘O’ update. Android Wear 2.0 reduces the number of system components that have to be processed in a software update.
- Android’s standard rendering path remains OpenGL ES 2.0. Vulkan is being talked about, but this team apparently doesn’t set the standards around here.
- Display color management won’t be available on the current Pixel phones as it is a measure that must be calibrated at the factory floor (and it wasn’t).
- While you can complain about the quality of a picture you sent to a social network from your Android phone, it all comes down to the APIs concerning the camera parts, the quality of the camera product itself and the acceptance of simpler or more complex APIs on the app side.
- SafetyNet is what prevents rooted users from using Android Pay and Netflix over DRM and data transmission concerns. “Ultimately, it is the app’s business decision to allow or not allow their services to be run on unlocked or rooted devices,” but Android does want to keep power users happy…
- Any potential for continuous platform and app updates? Not really — OEMs and APIs have months-long stakes that need to be addressed.
Finally, a little perspective that’s best delivered in whole:
/u/goldfingerrand: What are some of the end user and/or developer expectations and/or behaviors that limit what you can improve in Android O and follow on Android releases?
Android engineer 1: From the System UI perspective we definitely always have to think about what kind of features we want to introduce, since it’s a million times harder to remove them again. Users are super sensitive to change, so we always have to find a balance between our past decisions and what’s best for the product. It’s especially hard to redesign whole interaction models that users are already accustomed to, but we’re still trying to put innovation at the core of our planning.
Android engineer 2: There’s no one-size-fits-all solution for 2 billion users. When designing new features, it’s tempting to try to address everyone’s needs, but taken too far, the experience gets overly complicated. On the other hand, oversimplifying a feature results in many users not getting their basic needs met. In every new feature we introduce, we need to strike a good balance between power and simplicity, and this takes time to get right.