It’s been a month since Google I/O 2018 took place. I finally managed to watch some presentations, read about it and try some new stuff. Android Work Manager that I’ve written about is pretty cool. But there is so much more in Android from Google I/O and previous months, it’s time to organise it into one post.
This is my take on the most important stuff, for whole (and probably too long) list of changes, see: new features and behaviour changes
Let’s get to business: Android P is not a revolution. As you might have already noticed, pattern is as follows: the more mature is Android, the less dealbreakers it introduces. And it’s really understandable. Most new stuff is about developer sanity, rather than shiny features for end-user.
Improvements for developer life
Android Jetpack
That’s the biggest one. If there is one important thing you should know after Google I/O 2018 it’s Android Jetpack. It is set of tools, guidelines and libraries to make developer life easier.
AndroidX
In short: AndroidX is the new support library. But this is understatement, as all new ‘official’ libraries (like Room, Architecture Components) will be a part of AndroidX. Essentially AndroidX is umbrella project to gather all external dependencies that are produced by Google’s Android team. Now there will be clear division between Android packages/classes and packages/classes that are bundled into app. Everything that is part of AndroidX will have package name starting with androidx.* - Android SDK has android.*.
Navigation Architecture Component
That is huge! Navigation inside app should be much simpler now, at least in theory. This is totally new approach to manage and combine transitions between screens. With Navigation Editor view you can see the whole app flow in one place. You can change transition destinations by moving arrows. And you should also get used to new xml file, nav_graph.xml.
Now developers should no longer fight with transitions, they should just declare them. And sending data with bundles between contexts? Now it is quite type-safe! It’s big and very promising topic.
Paging
Another project under Android Jetpack. It’s not super interesting to me, but worth mentioning nonetheless. Paging allows to easily handle lists with many (or infinite) number of elements that needs to be loaded easily.
Opinions
Android FINALLY is opinionated. Times of ‘Which architecture should we use? The one that works best for your app!’ is over. It started to be over last year when Architecture Components were introduced, but this year its official. Android team finally says which approach they suggest, they have their own opinion and it gives much much smoother start. Of course you can still do whatever you like, but now there is some guideline, the default way to do things. Currently it is: use MVVM and activity with multiple fragments (and with Navigation Component soon).
Android KTX
Ok, I love Kotlin, so I might be biased here, but I’m very happy that Google encourages to use Kotlin and all its cool features. Android KTX is a bunch of wrappers or extension methods for Android SDK that makes your code more readable and error-proof at the same time. You can’t say no to this!
When AndroidX will be fully released it should be the default option. Old support library will be release for Android P but that will be its last release.
Slices
Slices are like widgets or quick actions but they show up only when they are needed. If you app makes sense in context of some search then yes, slices are for you. With given templates you can create small embeddable view that will show up when Android decides it might be helpful for user. From user perspective that probably the biggest change - this is one of a few new features, not just improvements for developers.
A bit of Flutter
The idea behind Flutter is really great. Render everything, so you are abstracted away from underlaying system and APIs. Thanks to this you can render everything on your desktop - isn’t that great? I’ve never tried Dart, but I think it’s high time to do this. Projects looks promising, but at the same time - a few multiplatform frameworks looked promising already, so who know. It’s a shame that Flutter played very small role at Google I/O. It seems focus is somewhere else.
Android App Bundle
Android App Bundle (.aap) is new format for packaging apps which makes final APK smaller. Packaged that way, Google Play will automatically generate multiple APKs for different device configurations and when someone downloads your app, it will download only necessary files, i.e. resources for given screen density, processor architecture and language. It makes app smaller and in future will even enable dynamic feature loading, which sounds very interesting.
Security, security everywhere
Which surely is a good thing.
First of all, app in background can no longer use camera or microphone. It’s good, because privacy is provided by the system. What is bad about it is flexibility - which is inversely proportional to security, unfortunately. There were several apps that made some smart use of this capability. Sure, with very limited and specific use cases but still. Anyway, I think Android needs more maturity than flexibility, so that’s a good change.
Another secure thing - https is now enforced, unless you explicitly state that some domains might be reachable with http.
Background work limitation
New version of Android - new background limitations! Firstly, there is a thing called ‘App Standby Buckets’. There are buckets to which app will be assigned to depending on how often it is used. Of course this buckets determine how often (if at all) app can do background work. Intersting fact - it works only when phone is not charging. For more info see: App Standby Buckets.
Moreover, if app is consuming “excessive resources”, system might notify user about it and ask to restrict the app.
Target API shaming
Since Android P old apps will be shamed or banned. By shamed I mean that when they are launched, popup is shown that „App was was built for older version of Android and might not work properly.” It looks bad for the end user, so it should convince developers to target newer Android. I don’t see it as something bad as not updated apps were always a big pain for Google.
I think it was made so that Google can finally break backward compatibility to some extent. Targeting older Android versions was always workaround for not following the rules of new Android. It’s not good for users (assuming that newer Android wants the best for users), but sometimes simpler for developers. And Google had to allow for this because compatibility. It ended now and I’m pretty happy about that. For interesting read, I recommend CommonsWare article about it.
Summary
Not much changed. As always you need to make sure your app runs regarding background work. But most apps should just work with new Android. The good thing is - they can be improved in code. So instead of fixing you app for Android P, you could make use of new AndroidX stuff and make your app more error-proof and easier to maintain.