It's no secret that Google advocates developing apps with multiple form factors in mind. While not all the apps in Google's own portfolio are quite up to speed on this front, apps like the ones in Google's Play suite have done a nice job so far in supporting phones and tablets alike.
But since I/O 2014, Google's been working on more than just phones and tablets. Last year saw the introduction of Android for TVs, watches, and even cars, so now is the time for developers to start thinking about how their experiences will look and feel on those new form factors.
To that end, Google has announced a new reference sample app - a music player - that's available for developers to play with.
At some point or another, most Android developers will eventually open up the profiling tools to track down bugs and performance issues in a misbehaving application. Let's be honest, the tools included with the Android SDK do leave something to be desired. Facebook has just released one of its internally-developed tools which provides network inspection, database inspection and interaction, and a support for access to the dumpapp output with the use of customizable plugins. The most interesting feature about Stetho is that it runs entirely through the Chrome Developer Tools – the same interface used by web developers everywhere.
Keep in mind, Stetho is not a total debugger replacement.
Months ago, we posted a rumor about "modular actions" set to come to Google's Search app (now just called Google) along with "Ok Google Everywhere" functionality that would allow users to activate search from anywhere on their device. The latter has already been implemented, but Google is still inching toward the former. With the technically unreleased Google app, the search interface can overlay apps from which it is called, but Google today announced another step forward - the ability to let apps hook into search by accepting voice queries from the user.
The solution is a mere six lines which, when added to the AndroidManifest.xml file, will allow a user to say something like "Search for pizza on Eat24" to open the corresponding app (in this case Eat24) to pizza search results.
Google I/O 2014 has come and gone, but that doesn't mean great stuff from the conference isn't still coming out. The companion app used by thousands of attendees -and hundreds of thousands of fans and followers- has been open sourced! Code for the I/O app is meant to serve as an example of best practices for Android developers, providing fully functioning implementations of the latest design principles, UI controls, networking code, and more.
It has become something of a tradition to release the source code for the I/O scheduler app, although this is only the 3rd time it has been done.
A new feature has snuck into the Chrome OS dev channel that, while not yet fully baked (okay, it's still mostly a block of ice), could one day allow users to unlock their Chromebooks automatically just by having their phone in close proximity. This feature is "Easy Unlock."
The Chromecast has identity issues. It may be based on Android, but it updates like Chrome. The device ships on the stable channel, but it's possible to switch it beta and dev channels. These options are progressively bleeding edge, but this comes at the obvious sacrifice of stability, and there's a strong risk of bricking your device. Granted, it's only $35, far cheaper than breaking a smartphone or tablet.
Disclaimer: Android Police isn't responsible for any harm to your device - proceed at your own risk.
You need root first, then manually push the zips to update, at which point you'll be switched to the respective channel.
Just like last year, the Google I/O app's source code has been released in an effort to get developers acquainted with Android best practices.
In a post to Google+ today, the Android Developers page outlined some of the things the source code has in store for those curious. Among them are techniques to implement responsive design across phones and tablets, use content providers and implicit intents in app navigation, using sync adapters to provide new content "in a battery-friendly way" and loads more.
If you're a developer who's been anxiously awaiting the code, a developer who had no idea the code was on its way, or just a curious onlooker, hit the appropriate link below to see the original Google+ post, or see the code.
If you like to tinker with Sony Xperia devices, things just got a little more fun (funner, if you will). Thanks to Sony's newly-released Illumination API, developers can now tweak the illumination bar settings on compatible devices, including the Xperia SP, ZL, ZR, UL, A U, L, S, SL, P, sola, ion, acro HD, go, M, and M dual.
Sony is calling the Illumination API an experimental API (the first of its kind for the company), which essentially means it will be released with limited documentation and virtually no support; basically, you're on your own with this one. Fortunately, it seems pretty straightforward – it can be used to control the LED color, the pulsation and time between pulses, as well as pre-defined fading patterns on certain models.
Between Hangouts, the gorgeous new Maps, Play Music All Access, and everything else discussed in I/O's opening keynote this morning, several revisions to the Play Store developer's console were announced.
Perhaps the most interesting addition to the console will be an organized method for alpha and beta testing, and staged rollouts. Basically, developers can select alpha and beta testers, receiving all feedback directly (instead of through reviews) and, when the time comes, roll out the app to certain percentages of the user base.
The changes also include a major help in ensuring your apps make sense to international users – a full translation service by which developers can order specific translations, come back a week or so later, and download the translations directly from the console.