There will be plenty of changes and new features "under the hood" in Android M, the as-yet-unnamed next major version of Android, which will be released later this year. We all love new features that we can see. But often the best — and most important — changes are deep down in the core, quietly doing their thing and making stuff better. These new and improved bits of code are what Google and third-party developers use to make magic happen.
We're getting a taste of what's to come now in the M Developer Preview. Some of us (guilty) get all gooey inside when we talk about new APIs and the powerful things developers can do with them. More of us probably would get gushing if these APIs were presented in easy-to-read-not-codemonkey-nerd dialect, and instead broken down in plain language without all the talk about classes, methods and services.
We brought out the Geek-to-English translator and we're going to have a look at the new Android M APIs, and talk about what they can do. Strap in.
What is an API?
This is the best place to start. We're going to talk about a handful of new APIs, so everyone needs to know what those three letters mean.
An API is a shortcut and a gatekeeper, and makes life easier on everyone.
API is an acronym for Application Programming Interface. Think of them as a sort of plugin that the folks who wrote the Android code have provided, and developers can use to communicate with the system and do "stuff" without writing out a bajillion lines of code themselves. APIs also allow developers to communicate with areas of Android that are protected, so the system can return information that would be otherwise unobtainable. So APIs are shortcuts as well as gatekeepers.
A developer writing an app for Android simply has to include the right classes, methods and services for the feature they want to implement, and all the heavy lifting is done elsewhere in the operating system. For example, take this bit of code to enable the new Direct Share API:
<activity android:name=".MyShareActivity" android:label="@string/share_activity_label"> <intent-filter> <action android:name="android.intent.action.SEND" /> </intent-filter> <meta-data android:name="android.service.chooser.chooser_target_service" android:value=".ChooserTargetService" /> </activity>
That is far easier than writing out all the code for one app to authenticate and define the targets for a particular intent so that their the correct app opens when you want to share something in a certain way, with a certain person. (See? Even explaining that isn't fun.)
Think of an API as a shortcut, where most of the work was done by Google, that developers can include in their code to use Android's features in their apps. This makes them powerful tools and makes for better apps.
Now that you have an idea of what an API is, let's have a look at an overview of the new APIs in Android M.
This allows an app — for instance the Android Central app — to make itself the default when a user (that's us!) taps a link to a URL — for example www.androidcentral.com. In Android's current state, we have to choose to let the AC app open links to Android Central. Using this new feature things can happen automatically.
To use this feature, the folks who own a website have to add some code to their site, use a valid security certificate, and add corresponding code into their app. Once that's done, clicking a link sent to you via any medium — SMS, email, social media, etc. — will open the link in the right app if you have it installed, without any further action or a dialog telling you to pick an application. This will allow website designers and developers to do things in a way that look better inside their app. We all want the web — and the apps we use to view it — to look better.
Auto Backup for Apps
This is now the default for all applications written to support Android M. Hooray!
No longer will developers be allowed to be lazy (or, worse, negligent) with data backup
The data for any app or game is now automatically backed up to Google Drive, and is automatically restored when you change or replace your phone or tablet. It's encrypted, each app can have 25MB to store settings and data, and none of it counts towards your Google Drive storage quota. Of course, you can opt out of this as you like.
When your photo or tablet is idle, charging and connected to Wifi, backups are done automatically every 24 hours. App developers can define which data folders are backed up, and when we move to a new device (or uninstall then reinstall an app), a restore operation copies the backed-up data into the app's data folders. If an app uses the old Android Backup Service, it trumps this new service so nothing changes for users of existing apps that have an automatic backup feature.
Native fingerprint authentication — where we can use a fingerprint scanner to verify our credentials to an app or service — has come to Android.
We've seen how useful fingerprint scanning can be (when done correctly) before — hello Samsung Galaxy S6 — but now that this is built into Android things will be easier for developers to implement and won't need to use a third-party SDK provided by the folks who made the phone.
It also means that more manufacturers may include a finger scanner now that they do not have to provide their own application support. (And if you spotted that fingerprint icon on the display there, maybe it means something. Or maybe it doesn't yet. We'll just have to see.)
Simply put, this new feature can be used to confirm your identity within an app based on your lock screen security.
Android will store a cryptographic key when you unlock your device. Applications can use this key and any associated tokens to authenticate or log in to them. Based on how recently you unlocked your device —and not just "turn on," but "enter some sort of code to unlock" — you can let an application know that you are really you using these secret key implementations.
Developers can choose the timeout period, and can also ask the user to re-authenticate at any time.
Used in conjunction with the Android Keystore system, applications can now be secure and convenient.
This is flipping awesome! Ever come across something so cool you just have to share it with your boss or your spouse or anyone else? Now you can do it easier. We love easier!
The Direct Share feature allows developers to define specific share targets from within their app. Besides the normal way to share things — like Hangouts, email or an app like Google Keep — developers can add folks from your contacts (we assume this means your starred contacts in Google) and define how to share — mail, SMS, etc.
This one looks to be a pretty powerful new feature, and we're excited to see it added to some of the great apps we use every day. Prepare yourself, Phil. I won't get tired of sending you stuff. Ever.
OK, Google. Turn on the lights.
That's one of the examples given for Voice Interactions coming to Android M. We can already do a lot of things using our voice, and the additions here will allow for better, more precise actions using voice commands.
Things like an "Are you sure?" prompt to verify an action, or a list of choices repeated back to the user then confirmed and more are possible using the new voice services and activities. Combined with Android Wear or Google Glass, we see some really cool ways to do "stuff" on your Android coming in the near future.
The Assist API
This gives developers a way to use an assistant (J.A.R.V.I.S.!?) to interact inside their applications. The assistant is system-wide, and a few lines of code will enable it (him? her? please have custom voices) within an application — if we have opted to use it.
There are methods in place to allow developers to choose whether they want to share what goes on between you and the assistant outside of their app, and system-wide security features will keep private data private and away from advertisers. In theory.
We've been waiting for Google to give third-party access to Google's Voice Assist features for a while. This one needs some serious testing (read: Jerry playing and talking to his Nexus 6 in the middle of the night) to see exactly how it will work, what it can do, and how we can break it. I love my job.
There are four important new features coming to Android Notifications:
- A new "Do Not Disturb" mode that actually allows alarms to disturb you
- A new category that allows user-created events to be separate from system events and alarms
- A new class that allows custom icons to be attached to notifications
- A new method that allows an app to see which notifications are currently "alive" and active
Developers can use these new modes and methods to distinguish what's important from what isn't, give us a visual cue about what we're getting notified of, and allow us to decide when and where notifications we asked for inside their apps should be given.
This all sounds great, but we'll also have to depend on developers using these new tools in the correct way. Notifications — and interacting with them — has historically been one of Android's strongest points. Additions to the way developers can customize and bolster their usefulness are always welcome.
Bluetooth Stylus support
If you've used a Galaxy Note 4 with the S Pen, you know how cool using an active stylus can be. We're talking actual interaction, and not just stabbing the display with a rubber-tipped stick. Google is providing support for Bluetooth styli in Android M, and some of the cool features we have seen in the Note series will be possible in vanilla Android.
When you pair and connect a compatible Bluetooth stylus, support for things like pressure sensitivity, screen touches and button (on-stylus buttons) is available and developers can leverage this data inside their apps.
Look for things like a dialog or app launcher when you press the button on your stylus, as well as better drawing and writing support to come to apps in Google Play when M is available.
4K Display Mode
Support for 4K (Ultra HD 3840 X 2160) resolution will be baked into Android M. While the merits of a 4K display on a smartphone can be discussed and debated to death, everyone will agree that this is great for things like Android TV.
UHD will soon become commonplace, and Android will be ready for it.
Phil, I need a new TV. For testing purposes. (Ed. note: No.)
A sort of theme engine is coming in Android M, and Google needs to provide a way for developers to support it in the navigation and menus of their apps. That's what we have here.
When a user selects to use a dark theme, words and images need to be a lighter color. The opposite is true if a user chooses a light theme. While much of the text and imagery components can be colorized by the system, these new methods allow developers to follow user applied color themes inside any portion of their app.
Android M will bring some new audio features to developers. Native support for the MIDI protocol will let devs send and receive MIDI events (think musician software like GarageBand here) and create objects that override system audio defaults.
Applications will be able to allow audio devices to hook into the system to support things like Voice Actions from a game controller or remote control. Like the controllers and remotes we see for Android TV devices.
Applications will also be able to retrieve a list of connected audio devices, which can be sorted and app audio routed through a specific source. The PlayStation 4 uses this sort of feature, where the controller's audio jack be be set to play chat audio while game audio is sent through the TV sound system.
While these new features are pretty specific, there is some really cool stuff here.
New capabilities to the video processing APIs include new ways to synchronize audio and video streams (I get twitchy when the mouth doesn't match the words when I watch a video, and I can't be the only one), and new ways to set and reclaim video instances to better support the DRM we all hate but know is necessary.
There's also a new method to set fast or slow motion in video that will automatically stretch or speed things up in tandem with the audio.
Again, these are pretty specific changes, but should be important to the people making apps that display video. And we all love to use apps that display video!
I'm going to go out on a limb and say that most of us have used the camera flash on our phone as a flashlight. I know I do it when Rex or Sammy (our dogs) decide they need to pee at 4 in the morning. Or when Jerry needs to do the same.
The new Flashlight API recognizes this. It exists only so that developers can use the camera LED as a flashlight without turning on the entire camera software stack, which is how it has to be done now.
This saves battery, as well as ensures that an improperly shut down flashlight application doesn't stay attached to the camera interface and other apps can't open it.
Little things like this mean a lot. Plus it's easier on developers.
Android for Work
When Android M goes live, we'll spend some time covering all the new Android for Work features. A lot of us are looking forward to them so we can ditch the company phone and BYOD to work. For now, here's a recap of what we can expect.
- Enhanced controls for Corporate-Owned, Single-Use devices: If you have a company phone that runs Android, the people who bought it have better control over a few things. Device owners can now disable/enable the keyguard, the status bar (including things like notifications, quick settings and gestures) and safe booting of the device. Device owners can also prevent the screen from turning off while plugged in if they have a reason.
- Silent install and uninstall of apps by Device Owner: Device owners can now install or uninstall applications with full use of the package manager, with no interaction from the user and outside of Google Play. This will let IT departments have a sort of automatic provisioning and install essential applications to any phone, even before a user has logged in with a Google account. (Google also sees this being used with Android-based kiosks.)
- Silent enterprise certificate access: This feature lets the folks who own your device grant managed apps access to certificates without user interaction. It's a security thing. And a good one.
- Auto-acceptance of system updates: The device owner can select to auto-accept updates, or postpone them with no action from the user. The user is unable to override this in the device settings. The device admin can also tell a device when to accept an update using a daily time window. Again, control. (And kiosks.)
- Delegated certificate installation: Device administrators and owners can allow third-party apps the ability to use other APIs to manage security certificates. Your company IT guys want this, even if you don't know (or care) what it does. More security things here.
- Enterprise factory reset protection: Device owners and admins can now configure any factory reset protection on your work phone. Your company needs to be able to control when — and who — can factory reset your work phone and these tools offer granular control.
- Data usage tracking: If your boss pays for your data. It's his or her right to keep track of how you use it. With Android M, they can do so easily.
- Runtime permission management: The device owner can set up parameters that decide what apps can be launched and run. The tools coming in Android M will allow the user to choose to allow apps to run, or let admins set a policy to restrict what apps can run. The user is unable to override this policy.
- Work status notification: When a user is using an application from any managed Android for Work profile, a briefcase icon will appear in the status bar. If a user unlocks the device while using an app in the managed profile, a pop up will remind them that they are in their work profile.
Android for Work is important. While we don't really want our boss deciding some of these things for us, company phones with company data need extra security. It's key for any serious Android adoption in the enterprise.
We'll dig deep into it all when it's available.
Under the hood of Android
This was just a quick look at the new API features that come with Android M. Each of them consists of many new methods and APIs that developers can leverage to include support for new features, and it certainly gets complicated. Most of us don't realize how much legwork and reading is needed to support new features, even before a single line of code is written. Devs work hard and deserve our appreciation and love. #HugYourDeveloper
This is why Google offers a developer preview in the first place. While we "discuss" the merits of the new app drawer (that very likely will change with the final release), application developers and designers are reading documentation, staying up all night and drinking Red Bull to see how they are going to implement new features into the apps we love. It's their job, and their passion.
All we have to do is look forward to seeing the great stuff they can do with it all.