Google I/O is first and foremost a developer conference. New products may be announced at the keynote, but just about everything is really meant for the people that build the apps. For Android developers, there are few things that matter more than their tools. Today, a fresh release of Android Studio hit the Canary channel, and it brings one of the most often requested features: C/C++ support.
Android apps, as most people think of them, are usually written in Java and have a runtime environment that imposes some additional overhead on execution.
With the Android M developer preview being made available to the public today, some of the secrets of Android's latest OS have been unwrapped and shown to the public. One secret that still remains is which dessert themed name beginning with M the next gen software will be known by.
Well, there is nothing that the internet does a better job of than spreading rumors, and the image on the face of Google's own David Burke's watch started a big one.
One year on, Google's material design philosophy is still picking up steam. As popular as it's become in the community though, there are still some holes left to fill in terms of implementation.
Until now, developers have had to rely on third-party libraries (in conjunction with Google's own support library) to create elements like floating action buttons, but Google is looking to fix that, releasing a new design support library today that fills in some of the holes.
Besides new family-friendly and kid-friendly efforts on search and discovery in the Play Store, Google announced during its keynote today that Play Store search will be getting smarter overall.
Specifically, Google wants to more effectively surface apps when users search for vague or topical queries. The example given in the screenshot above shows the user searching for "shopping" apps. The Play Store then returns, of course, shopping apps. But those apps are then categorized intelligently into different sub-genres like Fashion and Coupons.
This may seem like a small tweak to most users, but - if Google is right - it will help introduce users to the right app when the user is not sure exactly what they're looking for, which is a good step in helping along discoverability in the Play Store as a whole.
We've all seen, probably many times, the common situation where you click a link on your Android device and you are then asked with which app you would like to open it. On one hand, this is a great feature; merely guessing could be very annoying and it is a sensible way to allow users to assign default apps. Sometimes, though, certain types of links should always open in a particular app without prompting the user.
A new addition to Android M, as discussed at I/O today, will allow that to happen. Developers can add an "autoVerify" attribute to their app manifest to tell the operating system that there is no need to prompt the user for certain types of links.
When it comes to getting users to your app, your Play Store listing counts for a lot. What users see (and read) when they reach your app's listing can make or break their decision to download or buy, so carefully crafting a good listing is important.
To that end, Google has announced that it will open up what amounts to A/B testing for Play Store listings, meaning developers can play with their listings by testing different screenshots, graphics, etc. to see what performs better and end up with the best possible listing.
To facilitate this, Google will add "Listing Experiments" to the Play Store developer console.
If you are sharing a link, you want whoever opens it to access the web service in whichever way makes the most sense on their device. On a desktop, you probably want to see it in a browser. On a mobile device, it often works better to open up that service's app. Google's URL shortening service, goog.gl, now offers that functionality. The same link will open either app or browser depending on the OS and whether an appropriate app is installed. Deep linking works on both Android and iOS.
This news is maybe most relevant to developers, but it should end up benefiting end users as well since you shouldn't have to deal with the confusion.
Writing great, high-quality software is hard work. No matter how well we know a platform or how long we spend on code, there are bound to be bugs. Memory leaks are among the most common problems, and they can be particularly disruptive on mobile devices. Square set out to make memory leaks easier to track down and fix with a new library called LeakCanary. It makes leak detection almost automatic and presents results in both logcat and an easy-to-read interface.
LeakCanary is designed to be as easy to use as possible. For most applications, it should only require a few additional lines in the app's build.gradle file, and one more line of code in your Application class.