Warning: Table './devblogsdb/cache_page' is marked as crashed and last (automatic?) repair failed query: SELECT data, created, headers, expire, serialized FROM cache_page WHERE cid = 'http://www.softdevblogs.com/?q=aggregator/sources/30' in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc on line 135

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 729

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 730

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 731

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 732
Software Development Blogs: Programming, Software Testing, Agile, Project Management
Skip to content

Software Development Blogs: Programming, Software Testing, Agile Project Management

Methods & Tools

Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!

Android Developers Blog
warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/common.inc on line 153.
Syndicate content
An Open Handset Alliance Project.
Updated: 6 hours 43 min ago

Get your apps and games ready for space with Google Play (April Fools')

Wed, 05/04/2016 - 00:14

Posted by Lily Sheringham, Google Play team

Google Play lets you distribute your apps and games to over 1 billion active Android users around the world. With advances in space exploration and the advent of galactic tourism, there will be a high number of users beyond this world that developers need to start thinking about, too. Google Play can now help you reach them. We’ve added new features to the Google Play Developer Console and updated the material design guidelines, to help you design, test, and distribute your apps and games in space.

Here’s a look at how The Guardian, one of the largest English-news organizations in the world, enhanced its Android app to enable astronauts and space travellers to stay informed and up-to-date, while in orbit or on the surface of the moon.


"I am pleased to have The Guardian's application to test the growing Interplanetary Internet" says Vint Cerf, distinguished visiting scientist at the Jet Propulsion Laboratory and Google's Chief Internet Evangelist. "The interstellar version is in development and I'm looking forward to having more Google Play apps and games tested in space flight."

Get your apps and games ready for take off today.

Categories: Programming

Find success on Google Play: What app developers can learn from games

Mon, 05/02/2016 - 18:14

Posted by Matteo Vallone, Business Development Manager at Google Play

(As a way to reach more app developers and help them grow successful businesses on Google Play, this post was first published on The Next Web – Ed.)

There is much common ground between freemium apps and games businesses when it comes to achieving success. Users are, however, more used to paying for games than apps, stemming from the history of traditional gaming consoles. Moreover, mobile games are also able to easily offer ‘virtual goods’ across a range of price points to suit every pocket. This means that game developers have had plenty of opportunity to learn about how to improve onboarding, conversion, and ultimately the user Lifetime Value (LTV). So what can app developers learn from game developers? Here are some best practice tips and insights from successful game developers that can be applied to many apps, today.

Drive app success the game developer way:

1. Optimize retention before investing in acquisition

Retention is king, and retention drives conversion. For games developers, retention is the key measure of game quality and whether it appeals to players.

Most game developers will “soft launch” to beta testing communities or test markets. During this phase, the game is tweaked to optimize retention by looking into specific areas, such as tutorial completion, level difficulty and conversion. Developers can then track retention using the Cohorts reports in Google Analytics. Once retention is satisfactory, the developer can go to full launch and start investing in user acquisition.

2. Retain users with step-by-step engagement

The first seven days after install are the most critical for retention: users install several apps to try them, and decide in the first few days which ones they want to keep using. If you can retain for that time span, your app is more likely to become part of the user’s daily routine.

There are some simple ways to progressively build user engagement. It’s important to present a strong story that explains why that app is relevant to the user, while introducing them to key features. Then place features that offer the user value early, so they can be found without much effort.

This is a not a one-size-fit-all. To find the right solution, a developer needs to first make assumptions on what user flows can improve retention and then run A/B tests to validate or correct them. For example, a developer could think that introducing sign-in later in the user flow might improve retention. Also, the developer needs to keep in mind what the key long term engagement metrics are for the individual app (such as photos uploaded or the number of articles read) and measure the impact of the different onboarding flows on those metrics as well.

In general, these principles are good places to start optimizing your onboarding:

  • Look for ways to let the users experience the app straight away, rather than taking them through a long, complex setup.
  • Present “activation moments” — such as registering an account, uploading a video, or finding friend — gradually
  • Start by requiring minimal investment by the user, then ask them for more details as they are needed to use the apps features.
  • Treat permissions as a service for the user. For example, if you want users to register, show them in advance that, by making their experience more personal, they’ll get more value from the app.

In this example, OkCupid tried different onboarding flows and found the most engaging version increased seven-day retention by over 20 percent.

Finally, ensure the user can understand the value of your app before you start asking them to pay. Game developers are particularly good at letting their users try most or all product features for free in in a set number of days or sessions.

A great tool to help analyze how users are engaging (or not) with the app is through the Flow Report in Google Analytics. Using this report, a developer can see how users navigate through the app and where they leave to identify potential roadblocks.

3. Target the right offers at the right users

Understanding different groups of users in-app purchase behavior is the key to devising strategies to encourage them to spend.

Start by identifying groups of users by how they spend and much they are likely to spend. It may be by age group, the channel that brought the install, or in-app behaviour. Use the Segment builder in Google Analytics to identify and define these groups of users. Then, tailor in-app purchase offers to match the segments spending behavior. For example, for segments where multiple users tend to spend more in one go, but spend infrequently, offer them in-app features bundled together.

4. Offer in-app purchases when users are most likely to spend

Users are also more likely to spend, if the purchasing experience is frictionless, and even more so when they can see how the expenditure will add value. So:

  • Present purchase opportunities to users when they’re most likely to need or want it — and explain to the user why it’s relevant.
  • Make purchasing accessible easily from within the app with a minimum number of taps. For example, offer an upgrade button on the footer of relevant screens.

TomTom added a countdown to indicate when the free service runs out (counted in kilometers travelled). The counter includes a button to upgrade offering a one tap in-app purchase.

Like all good game developers, they focus on building good experiences that retain and engage users through constant testing and analytics. First impressions are important, so users need to be able to quickly understand the importance of the app and easily navigate through the onboarding experience. And to start generating revenue, it is important to be thoughtful about how to make in-app purchases actionable.

Watch Matteo’s Playtime 2015 session ‘The rules of games, for apps’ to hear more in-depth insights which app developers can learn from games with best practices and developer examples:

You can also watch the other sessions from Google Playtime 2015 to learn more about tools and best practices which can help you find success with business on Google Play.

Categories: Programming

Game developers, get ready for our Developer Day at GDC 2016

Mon, 05/02/2016 - 18:14

Posted by Morgan Dollard, Product Manager of Google Play Games

Next week, we’ll be in San Francisco to host our annual Developer Day at the Game Developers Conference (GDC). Join us to get a first look at our latest efforts to help developers of all sizes build successful mobile games businesses with powerful tools to develop high quality apps, grow a valuable user base, and earn more revenue.

Our Developer Day will take place in room 2020 of the West Hall of Moscone Center on Monday, March 14. Based on your feedback from last year, we're going to keep presentations short and informative with lightning talks around virtual reality, the cloud, ads, and so much more, while dedicating more time to interactive discussions with Google engineers and your peers in the industry.

Here’s a glimpse of the agenda on Monday, March 14:

Opening keynote || 10AM: Be the first to see what’s new and hear about the investments Google is making to help mobile developers grow their game business.

Best practices for success on Google Play || 10:30AM: In this talk, you’ll learn how successful mobile game developers acquire users and bring them back to keep them playing longer.

Lightning talks || 11:15AM: A series of 5-minute talks on innovative technologies to tantalize players, like Project Tango, software to speed and simplify game development, and new ways to predict and prevent user churn.

Interactive roundtables || 2:00PM: After lunch, we’ll break up into interactive roundtables to interact with Google experts and peers on how to build better and more successful games. Ask questions, tell Google product teams what you need, and learn from fellow game developers.

Visit the agenda page to get a full list of our talks and speaker details. Please note that these events are part of the official Game Developer's Conference, so you will need a pass to attend.

For everyone who can’t make it in person, we’ll be live streaming our event on YouTube. Tune in from 10am on Monday, March 18.

Categories: Programming

Grow your games business on Google Play: Game parameters management, video recording, streaming ads, and more

Mon, 05/02/2016 - 18:13

Posted by Morgan Dollard, Product Manager of Google Play Games

With mobile gamers across 190 countries, Google Play Games is made up of a vibrant and diverse gaming community. And these players are more engaged than ever. Over the past year, the number of games reaching over 1 million installs grew by 50 percent.

Today, at our annual Developer Day at the Game Developers Conference, we announced new platform and ads tools for developers, of all sizes reach, to reach this global audience and accelerate the growth of their games business. Check out below the full range of features that will help game developers build their apps, grow their user base, and earn more revenue.

Making Google Play Games better for players

In February, we introduced Gamer IDs so that anyone could create a gaming persona. We also simplified the sign-in process for Google Play Games so players could pick up playing their game more quickly. We’re also working on product enhancements to make Play Games a little more social and fun, which will mean more engaged players who’re playing your game for longer. One example is the launch of Gamer friends (coming soon!), where your players can add and interact with their friends from within the Google Play Games app (without needing a Google+ account).

We’re also launching the Indie Corner, a new collection on Google Play, that will highlight amazing games built by indie developers. You can nominate your awesome indie game for inclusion at g.co/indiecornersubmission. We’ll pick the best games to showcase based on the quality of the experience and exemplary use of Google Play game services.

Grow your game with powerful new features from Google Play game services

In January, we added features to Player Analytics, the free reporting tool of Google Play game services, which helps you understand how players are progressing, spending and churning. Today, we previewed some upcoming new tools that would be available in the coming months, including:

  • Game parameters management: With game parameters management, you will be able to update gameplay and game economy parameters without the need for APK changes or resubmitting your app. You’ll be able to optimize virtual goods and currencies from the Developer Console or the Google Play Developer API.

Game parameters management in the Google Play Developer Console

  • Video Recording API: You will be able to easily add video recording to your app and let users share their videos with their friends and on YouTube in a few simple steps. We are also adding live streaming functionality to allow your fans to broadcast their gameplay experiences in real time on YouTube.
  • Predictive Analytics: The Player Stats API now has Predictive Analytics to help you identify which groups of players are likely to spend or churn, and we are adding new predictions for how much a player is likely to spend within 30 days and the probability that a player is a high spender. This allows you to tailor experiences for these players to try to increase their spend or engagement. Learn more about the Player Stats API.

“Not showing ads to users that were probable to spend increased number of IAP transactions by 15%.” – Avetis Zakharyan, CEO Underwater Apps

New ad formats and targeting to find, keep and monetize high-quality gamers

Promoting your game and growing your audience is important, but it’s just as important to reach the right audience for your game, the players who want to open the game again and again. That’s why today we’ve unveiled new features that make it simpler to reach the right audience at scale.

  • Search Trial Run Ads: In the next few weeks, we’ll launch a new way for users to try your game out when they do a search for games on Google through a new ad format, Search Trial Run Ads. After tapping “Try now”, an individual can play your game for up to 10 minutes, and then download the game in full if they choose. These ads will appear to smartphone users on WiFi. Using this format, you can drive qualified users who are likely to stay engaged with your game after install.

SGN’s Search Trial Run Ad for Panda Pop

  • Portrait Video Ads: More than 80% of video ad views in mobile apps on the Google Display Network are from devices held vertically, but often these videos are created for landscape viewing. Over the next few weeks, we’re launching Portrait Video Ads for a full-screen, immersive portrait video experience. Developers have seen significant improvement in both click-through and conversion rates, resulting in lower cost per install and more installs.
  • Active User Targeting for Games: In the coming weeks, we’re rolling out a new type of targeting for Android apps that allows you to show ads to users who have spent more than 30 minutes playing games, or who have played a Google Play Games integrated game, in the last 30 days.
Earn more revenue in your game with AdMob

AdMob helps game developers around the world maximize revenue through in-app advertising. At GDC, we also announced a new way to help you earn more through AdMob Mediation. Rewarded advertising is a popular form of game monetization -- users are given the choice to engage with ads in exchange for an in-app reward. AdMob Mediation will enable you to easily monetize your apps with rewarded video ads from a number of ad providers. Supported networks and platforms include AdColony, AppLovin, Chartboost, Fyber, Upsight and Vungle, with more being added all the time.

You can learn more about this, and all our ads announcements on the Inside AdWords blog.

This is just the start of what we’ve got planned for 2016. We hope you can make use of these tools to improve your game, engage your audience, and grow your business and revenue.

Categories: Programming

The Google Play Awards coming to Google I/O

Mon, 05/02/2016 - 18:12

Posted by Purnima Kochikar, Director, Apps and Games Business Development, Google Play

Google Play has seen tremendous growth over the past year, reaching more than 1 billion Android users across 190 countries. As a way to recognize our incredible developer community and highlight some of the best apps and games, we’re kicking off our first-ever Google Play Awards.

The program will showcase five nominees across 10 award categories and feature them in a dedicated collection on Google Play. Nominees were selected by a panel of experts on the Google Play team based on criteria emphasizing app quality, innovation, and having a launch or major update in the last 12 months. The winners of each category will be announced at Google I/O in May.

The full list of categories and nominees are below:

Standout Startup

Apps from new developers that offer a unique experience while achieving strong install growth. And the nominees are...

Dubsmash Hopper Musical.ly Robinhood Vrse Standout Indie

Games from indie developers that focus on artistic design, high quality and innovative gameplay. And the nominees are...

Alphabear Alto’s Adventure Fast like a Fox Neko Atsume: Kitty Collector Prune Best Families App

Apps or games with family friendly design that encourage creativity and exploration. And the nominees are...

Card Wars - Adventure Time LEGO Jurassic World™ My Very Hungry Caterpillar Thinkrolls 2 Toca Nature Best Use of Material Design

First-class implementation of material design concepts that deliver an immersive and innovative user experience. And the nominees are...

Bring! Robinhood The Fabulous Todoist Vevo Best Use of Google Play Game Services

High quality games with several strong GPGS feature implementations. And the nominees are...

Sea Battle 2 Table Tennis Touch Tapventures TowerMadness 2 Zombie Highway 2 Early Adopter

Early adopter of a nascent technology or platform, providing a delightful user experience. And the nominees are...

Glide Mechanic Escape Minecraft: Story Mode World Around Me Zumper Go Global

Apps or games with great localization and culturalization, or subject matter appeal, across multiple regions. And the nominees are...

Dragon Ball Z Dokkan Battle Freeletics Bodyweight Memrise Musixmatch Pokémon Shuffle Mobile Most Innovative

Apps or games offering a highly engaging novelty experience or unique benefit. And the nominees are...

Fast like a Fox NYT VR SmartNews The Fabulous This War of Mine Best App

A true representation of beautiful design, intuitive UX and high user appeal, quality and rating. And the nominees are...

BuzzFeed News Colorfy Houzz TuneIn Radio Yummly Best Game

Games with strong mechanics, informative tutorial, broad appeal and tasteful design. And the nominees are...

Alphabear Clash of Kings Clash Royale MARVEL Future Fight Star Wars™: Galaxy of Heroes

Join us live at the ceremony on May 19th at 7:00 pm PDT on stage 7 at Google I/O or via the live stream. You can also track the conversation on Twitter and G+ using the hashtags #io16.

Categories: Programming

Enhancing App Security on Google Play

Fri, 04/29/2016 - 21:44

Posted by Eric Davis, Android Security Team

We’re constantly investing in new tools and services to help developers build secure Android applications. This includes the application sandbox and Security APIs in the platform, Security APIs in Google Play Services, and even open source testing tools. Last year, Google Play also helped developers enhance the security of their applications by looking directly at the code they’ve written and offering suggestions for improvements.

The Google Play App Security Improvement Program is the first of its kind. It has two core components: We provide developers with security tips to help them build more secure apps, and we help developers identify potential security enhancements when uploaded to Google Play. This week, to help educate developers, Kristian Monsen, one of our engineers, gave a presentation about security best practices at the Samsung Developer Conference. And in 2015, we worked with developers to improve the security of over 100,000 apps through the program.

How it works

Before any app is accepted into Google Play, it is scanned for safety and security, including potential security issues. We also continuously re-scan the over one million apps in Google Play for additional threats.

If your app is flagged for a potential security issue, you will be notified immediately to help you quickly address the issue and help keep your users safe. We’ll deliver alerts to you using both email and the Google Play Developer Console, with links to a support page with details about how to improve the app.


Typically, these notifications will include a timeline for delivering the improvement to users as quickly as possible. Applications may be required to make security improvements before any other app updates can be be published.

You can confirm that you’ve fully addressed the issue by uploading the new version of your app to the Google Play Developer Console. Be sure to increment the version number of the fixed app. After a few hours, check the Developer Console for the security alert; if it’s no longer there, you’re all set!

The success of this program rests on our partnership with you—the developers of apps on Google Play—and the security community. We’re all responsible for providing safe, secure apps to our users. For feedback or questions, please reach out to us through the Google Play Developer Help Center. To report potential security issues in apps, please reach out to us at security+asi@android.com.

Categories: Programming

An Outsourcing Playbook for Android development

Fri, 04/29/2016 - 17:23

Posted by Rupert Whitehead, Developer Relations

We recently updated The Secrets to App Success on Google Play with tools and tips to help app and game developers grow successful businesses on Google Play. However, many great apps are created by agencies and freelancers on behalf of companies. Today, we’re releasing a new playbook to help companies of any size who are considering outsourcing their Android app development.

How do you choose an agency? What are the pitfalls you should avoid? What can you do to make your app successful? These are some of the questions tackled by the new Outsourcing Playbook that you can read on Google Play.


Let us know your feedback

Once you’ve checked out the guide, we’d love to hear your feedback so we can continue to improve our developer resources and support. Let us know what you think.

Categories: Programming

Developing for Direct Boot

Thu, 04/28/2016 - 22:59

Posted by Wojtek Kaliciński, Developer Advocate

Starting with Android N, a device that has been powered on can boot into a new mode called Direct Boot before the user has a chance to unlock it for the first time. In this mode, the operating system is fully operational, but access to private app data is limited and only apps that have been updated to be Direct Boot aware can run.

Is Direct Boot right for my app?

Not every app should run in Direct Boot mode, so before you start coding check if your app fits these common use cases:

  • Apps that schedule alarms, such as alarm clocks.
  • Apps that provide important and timely notifications, like messaging apps.
  • Apps that provide services to other apps or the system, such as Accessibility Services.

Please note that this is not an exhaustive list and we look forward to seeing what other kinds of apps can benefit from Direct Boot.

Making your app Direct Boot aware

In order to let your app run before the user unlocks the device, you have to explicitly mark components as being Direct Boot aware in the manifest:

 <activity|provider|receiver|service ...  
     android:directBootAware=”true”>  

You can pick the subset of your app components that need to be Direct Boot aware, but if you are using a custom Application class, it is assumed to be Direct Boot aware if any component inside your app is marked as Direct Boot aware.

For apps that need to run as soon as the system starts in Direct Boot mode, there is a new Intent.ACTION_LOCKED_BOOT_COMPLETED broadcast. All apps will still receive Intent.ACTION_BOOT_COMPLETED after the user unlocks the device.

Using the device protected storage area

To support running apps before the user provides the credentials needed to unlock private app data, all Android N devices now provide two storage locations for data:

  • Credential protected storage, which is the default storage location for all apps, available only after the user has unlocked the device
  • Device protected storage, which is a new storage location that can be accessed at all times when the device is booted, including during Direct Boot

Components of your app that are marked as Direct Boot aware must rely on device protected storage for any data required for their operation during Direct Boot mode. They may still access credential protected storage after the user has unlocked the device.

To access device protected storage you need to create and use a secondary Context object for all file-related APIs:

 Context deviceProtectedContext = context.createDeviceProtectedStorageContext();  
 deviceProtectedContext.openFileInput( ... )  

When your app gets updated to a Direct Boot aware version, you might have previously saved Shared Preferences or databases that need to be migrated to device protected storage. You should use Context.moveSharedPreferencesFrom() and Context.moveDatabaseFrom() before accessing them to make sure the app continues to work properly even when data is backed up and restored from older versions or other devices.

Things to watch out for

You should think carefully about what you put in the device protected storage. This should be a minimum set of data that will let your app work during Direct Boot. For example, in a messaging app you could store an access token with a narrow scope that only has access to the number of new messages on your server. All sensitive, private information, like the full message history and a read/write access token, should still be saved in credential protected storage.

Another thing to remember is that during Direct Boot apps can only access other Direct Boot aware apps and components. If your app depends on external Services and Activities, make sure you gracefully handle the situation when they’re not available. Intent filters will by default match only components available in the current user state (locked / unlocked). There are two new flags for explicitly telling the Package Manager which components to enumerate: PackageManager.MATCH_DIRECT_BOOT_AWARE and PackageManager.MATCH_DIRECT_BOOT_UNAWARE.

What’s next?

Until devices with Android N that support Direct Boot out of the box are released, you can test your apps using Android N Developer Preview builds. On Nexus 5X and Nexus 6P, you can wipe all user data and enable full Direct Boot mode by using Settings > Developer options > Convert to file encryption. Alternatively, you can reboot into bootloader and issue the appropriate fastboot command:

 $ adb reboot-bootloader  
 $ fastboot --wipe-and-use-fbe  

Warning: Both methods will perform a factory reset and delete all user data on your device.

Alternatively, you can use an emulated Direct Boot mode. To enable it, set a lock pattern on the device, choose "No thanks" if prompted for a secure start-up screen when setting a lock pattern, and then use the following adb shell commands to enable and disable emulation:

 $ adb shell sm set-emulate-fbe true  
 $ adb shell sm set-emulate-fbe false  

Please note that using these commands will cause your device to reboot. You should only be using emulated Direct Boot mode on test devices, as it may cause data loss.

#BuildBetterApps

Follow the Android Development Patterns Collection for more!

Categories: Programming

Android Studio 2.1 supports Android N Developer Preview

Thu, 04/28/2016 - 22:59

Posted by Jamal Eason, Product Manager, Android

With the launch Android N Developer Preview, we wanted to give you an easy and comprehensive way to build, test and validate your apps on the latest release with Android Studio. Built on the speed and feature enhancements of Android Studio 2.0, the stable release of Android Studio 2.1 includes updates to the IDE wizards, build system and Android Emulator so that you can try out new features and APIs of the developer preview including the new Jack compiler and Java 8 language support. In addition to support for the N Developer Preview, Android Studio 2.1 also includes performance improvements to Instant Run which leads to faster edit and deploy build speeds. If you are developing and validating your app with the N Developer Preview or want faster Instant Run speeds, you should download or update on the stable release channel to Android Studio 2.1.

Android Studio 2.1 includes the following new features:

  • N Developer Preview Support: Android Studio 2.1 is the best IDE to test and validate your app with the N Developer Preview. Get the latest versions of the preview SDK, experiment with the new Java 8 support, and gain access to the only official Android Emulator able to run N Developer Preview Emulator System Images to help in your testing.
  • Instant Run: For those of you who enjoyed the fast edit, build and deploy cycle with Android Studio 2.0, Instant Run now can now update incremental changes to your app code significantly faster.

Deeper Dive into the New Features

N Developer Preview

On top of new features and APIs of the N Developer Preview, Android Studio 2.1 release includes support for the new Jack compiler and support for Java 8. With the Jack compiler, lambdas, method references, compile-time type annotations, intersection types and type inference are available on all versions of the Android platform. Default and static methods and repeatable annotations are available on Android N and higher. To use Java 8 language features when developing with the N Developer Preview, you need to use the Jack compiler. The New Project Wizard [File→ New→ Project] generates the correct configurations for projects targeting the N.

Getting started with development is as easy generating a new project or updating a few settings in your existing project. Once you are ready to test, you can create a fresh Android Virtual Device (AVD) and run your app on the N Developer Preview using the new Android Emulator.


N Developer Preview on the new Android Emulator

Instant Run & General Build Performance Improvements

Instant Run and general build speed are now faster with two new features: incremental Java compilation and in-process dex.

In previous versions of Android Studio, a single line of Java code change will cause all the Java sources in the module to be recompiled. Now in Android Studio 2.1, incremental Java compilation is enabled by default to reduce compilation time by compiling only what is needed.

We are also speeding up build times by using in-process dex, which converts class files to dex files within the Gradle daemon process. This avoids the costly processing operation of creating separate dex processes. To use this feature, you will need to increase the amount of memory available to the Gradle daemon to at least 2GB (1 GB is the default). This feature will help speed up both incremental and full builds.

We’d appreciate your feedback as we continue to improve Instant Run and general build performance. We are going to keep working on making build times even faster in coming releases. Click here to learn even more about the build changes.

What's Next

Update

If you are using a previous version of Android Studio, you can check for updates on the Stable channel from the navigation menu (Help → Check for Update [Windows/Linux] , Android Studio → Check for Updates [OS X]). If you need a new copy of Android Studio, you can download it here.

Test and Validate Apps with N Developer Preview

After you update to or download Android Studio 2.1 and you want to test and develop your apps with the N Developer Preview, create a fresh Android Virtual Device (AVD) for the new Android emulator, and check out these additional setup instructions.

We appreciate any feedback on things you like, issues or features you would like to see. Connect with us -- the Android Studio development team -- on our Google+ page or on Twitter.

Categories: Programming

Building TV Channels

Thu, 04/28/2016 - 22:59

Posted by Josh Gordon, Developer Advocate

Channel surfing is a popular way of watching TV. You pick up the remote, lean back, and flip through channels to see what’s on. On Android TV, app developers can create their own channel-like experiences using the TV Input Framework.

To the user, the channels you create look and feel just like regular TV channel. But behind the scenes, they stream video over the internet. For example, you can create a channel from a video playlist.

Watch this DevByte for an overview of how to build to a channel, and see the sample app and developer training for more info. The sample shows how to work with a variety of media formats, including HLS, MPEG-Dash, and HTTP Progressive.



If you already have an app that streams video, consider also making your content available as a channel. It’s a great opportunity to increase engagement. We’re excited to see what you develop, and look forward to seeing your content on the big screen!

Categories: Programming

Android Support Library 23.2

Wed, 04/27/2016 - 22:40

Posted by Ian Lake, Developer Advocate

Android Support Library 23.2

When talking about the Android Support Library, it is important to realize this isn’t one monolithic library, but a whole collection of libraries that seek to provide backward-compatible versions of APIs, as well as offer unique features without requiring the latest platform version. Version 23.2 adds a few new support libraries as well as new features to many of the existing libraries.


Support Vector Drawables and Animated Vector Drawables

Vector drawables allow you to replace multiple png assets with a single vector graphic, defined in XML. While previously limited to Lollipop and higher devices, both VectorDrawable and AnimatedVectorDrawable are now available through two new Support Libraries support-vector-drawable and animated-vector-drawable, respectively.

Android Studio 1.4 introduced limited support for vector drawables by generating pngs at build time. To disable this functionality (and gain the true advantage and space savings of this Support Library), you need to add vectorDrawables.useSupportLibrary = true to your build.gradle file:


 // Gradle Plugin 2.0+  
 android {  
   defaultConfig {  
     vectorDrawables.useSupportLibrary = true  
    }  
 }  

You’ll note this new attribute only exists in the version 2.0 of the Gradle Plugin. If you are using Gradle 1.5 you’ll instead use


 // Gradle Plugin 1.5  
 android {  
   defaultConfig {  
     generatedDensities = []  
  }  

  // This is handled for you by the 2.0+ Gradle Plugin  
  aaptOptions {  
    additionalParameters "--no-version-vectors"  
  }  
 }  

If you are using AppCompat 23.2.0, setting these flags is required. This requirement has been relaxed as of AppCompat 23.2.1 and the flags are only required if you wish to use support vector drawables.

You’ll be able to use VectorDrawableCompat back to API 7 and AnimatedVectorDrawableCompat on all API 11 and higher devices. Due to how drawables are loaded by Android, not every place that accepts a drawable id (such as in an XML file) will support loading vector drawables. Thankfully, AppCompat has added a number of features to make it easy to use your new vector drawables.

Firstly, when using AppCompat with ImageView (or subclasses such as ImageButton and FloatingActionButton), you’ll be able to use the new app:srcCompat attribute to reference vector drawables (as well as any other drawable available to android:src):


 <ImageView  
  android:layout_width="wrap_content"  
  android:layout_height="wrap_content"  
  app:srcCompat="@drawable/ic_add" />  

And if you’re changing drawables at runtime, you’ll be able to use the same setImageResource() method as before - no changes there. Using AppCompat and app:srcCompat is the most foolproof method of integrating vector drawables into your app.

You’ll find directly referencing vector drawables outside of app:srcCompat will fail prior to Lollipop. However, AppCompat does support loading vector drawables when they are referenced in another drawable container such as a StateListDrawable, InsetDrawable, LayerDrawable, LevelListDrawable, and RotateDrawable. By using this indirection, you can use vector drawables in cases such as TextView’s android:drawableLeft attribute, which wouldn’t normally be able to support vector drawables.

As of Android Support Library 23.3.0, support vector drawables can only be loaded via app:srcCompat or setImageResource()..

AppCompat DayNight theme

While enabling the use of vector graphics throughout your app is already a large change to AppCompat, there’s a new theme added to AppCompat in this release: Theme.AppCompat.DayNight.


Prior to API 14, The DayNight theme and its descendents DayNight.NoActionBar, DayNight.DarkActionBar, DayNight.Dialog, etc. become their Light equivalents. But on API 14 and higher devices, this theme allows apps to easily support both a Light and Dark theme, effectively switching from a Light theme to a Dark theme based on whether it is ‘night’.

By default, whether it is ‘night’ will match the system value (from UiModeManager.getNightMode()), but you can override that value with methods in AppCompatDelegate. You’ll be able to set the default across your entire app (until process restart) with the static AppCompatDelegate.setDefaultNightMode() method or retrieve an AppCompatDelegate via getDelegate() and use setLocalNightMode() to change only the current Activity or Dialog.

When using AppCompatDelegate.MODE_NIGHT_AUTO, the time of day and your last known location (if your app has the location permissions) are used to automatically switch between day and night, while MODE_NIGHT_NO and MODE_NIGHT_YES forces the theme to never or always use a dark theme, respectively.

It is critical that you test your app thoroughly when using the DayNight themes as hardcoded colors can easily make for unreadable text or icons. If you are using the standard TextAppearance.AppCompat styles for your text or colors pulled from your theme such as android:textColorPrimary, you’ll find these automatically update for you.

However, if you’d like to customize any resources specifically for night mode, AppCompat reuses the night resource qualifier folder, making it possible customize every resource you may need. Please consider using the standard colors or taking advantage of the tinting support in AppCompat to make supporting this mode much easier.

Design Support Library: Bottom Sheets

The Design Support Library provides implementations of many patterns of material design. This release allows developers to easily add bottom sheets to their app.

By attaching a BottomSheetBehavior to a child View of a CoordinatorLayout (i.e., adding app:layout_behavior="android.support.design.widget.BottomSheetBehavior"), you’ll automatically get the appropriate touch detection to transition between five state:

  • STATE_COLLAPSED: this collapsed state is the default and shows just a portion of the layout along the bottom. The height can be controlled with the app:behavior_peekHeight attribute (defaults to 0)
  • STATE_DRAGGING: the intermediate state while the user is directly dragging the bottom sheet up or down
  • STATE_SETTLING: that brief time between when the View is released and settling into its final position
  • STATE_EXPANDED: the fully expanded state of the bottom sheet, where either the whole bottom sheet is visible (if its height is less than the containing CoordinatorLayout) or the entire CoordinatorLayout is filled
  • STATE_HIDDEN: disabled by default (and enabled with the app:behavior_hideable attribute), enabling this allows users to swipe down on the bottom sheet to completely hide the bottom sheet

Keep in mind that scrolling containers in your bottom sheet must support nested scrolling (for example, NestedScrollView, RecyclerView, or ListView/ScrollView on API 21+).

If you’d like to receive callbacks of state changes, you can add a BottomSheetCallback:


 // The View with the BottomSheetBehavior  
 View bottomSheet = coordinatorLayout.findViewById(R.id.bottom_sheet);  
 BottomSheetBehavior behavior = BottomSheetBehavior.from(bottomSheet);  
 behavior.setBottomSheetCallback(new BottomSheetCallback() {  
    @Override  
    public void onStateChanged(@NonNull View bottomSheet, int newState) {  
      // React to state change  
    }  
      @Override  
      public void onSlide(@NonNull View bottomSheet, float slideOffset) {  
       // React to dragging events  
   }  
 });  

While BottomSheetBehavior captures the persistent bottom sheet case, this release also provides a BottomSheetDialog and BottomSheetDialogFragment to fill the modal bottom sheets use case. Simply replace AppCompatDialog or AppCompatDialogFragment with their bottom sheet equivalents to have your dialog styled as a bottom sheet.

Support v4: MediaBrowserServiceCompat

The Support v4 library serves as the foundation for much of the support libraries and includes backports of many framework features introduced in newer versions of the platform (as well a number of unique features).

Adding onto the previously released MediaSessionCompat class to provide a solid foundation for media playback, this release adds MediaBrowserServiceCompat and MediaBrowserCompat providing a compatible solution that brings the latest APIs (even those added in Marshmallow) back to all API 4 and higher devices. This makes it much easier to support audio playback on Android Auto and browsing through media on Android Wear along with providing a standard interface you can use to connect your media playback service and your UI.

RecyclerView

The RecyclerView widget provides an advanced and flexible base for creating lists and grids as well as supporting animations. This release brings an exciting new feature to the LayoutManager API: auto-measurement! This allows a RecyclerView to size itself based on the size of its contents. This means that previously unavailable scenarios, such as using WRAP_CONTENT for a dimension of the RecyclerView, are now possible. You’ll find all built in LayoutManagers now support auto-measurement.

Due to this change, make sure to double check the layout parameters of your item views: previously ignored layout parameters (such as MATCH_PARENT in the scroll direction) will now be fully respected.

If you have a custom LayoutManager that does not extend one of the built in LayoutManagers, this is an opt-in API - you’ll be required to call setAutoMeasureEnabled(true) as well as make some minor changes as detailed in the Javadoc of the method.

Note that although RecyclerView animates its children, it does not animate its own bounds changes. If you would like to animate the RecyclerView bounds as they change, you can use the Transition APIs.

Custom Tabs

Custom Tabs makes it possible to seamlessly transition to web content while keeping the look and feel of your app. With this release, you’ll now be able to add actions to a bottom bar for display alongside the web content.

With the new addToolbarItem() method, you’ll be able to add up to currently 5 (MAX_TOOLBAR_ITEMS) actions to the bottom bar and update them with setToolbarItem() once the session has begun. Similar to the previous setToolbarColor() method, you’ll also find a setSecondaryToolbarColor() method for customizing the background color of the bottom bar.

Leanback for Android TV

The Leanback Library gives you the tools you need to easily bring your app to Android TV with many standard components optimized for the TV experience. The GuidedStepFragment received a significant set of improvements with this release.

The most visible change may be the introduce of a second column used for action buttons (added by overriding , android.os.Bundle)">onCreateButtonActions() or calling )">setButtonActions()). This makes it much easier to reach completion actions without having to scroll through the list of available GuidedActions.

Speaking of GuidedActions, there’s a number of new features to allow richer input including editable descriptions (via descriptionEditable()), sub actions in the form of a dropdown (with )">subActions()), and a GuidedDatePickerAction.


These components should make it much easier for you to get information from the user when absolutely required.

Available Now

Version 23.2 of the Android Support Library is available via your SDK Manager and Android Studio. Take advantage of all of the new features as well as additional bug fixes starting now! As always, file bug reports at b.android.com and connect with other developers on the Android Development Google+ community.

Categories: Programming

Android Studio 2.1 supports Android N Developer Preview

Tue, 04/26/2016 - 22:49

Posted by Jamal Eason, Product Manager, Android

With the launch Android N Developer Preview, we wanted to give you an easy and comprehensive way to build, test and validate your apps on the latest release with Android Studio. Built on the speed and feature enhancements of Android Studio 2.0, the stable release of Android Studio 2.1 includes updates to the IDE wizards, build system and Android Emulator so that you can try out new features and APIs of the developer preview including the new Jack compiler and Java 8 language support. In addition to support for the N Developer Preview, Android Studio 2.1 also includes performance improvements to Instant Run which leads to faster edit and deploy build speeds. If you are developing and validating your app with the N Developer Preview or want faster Instant Run speeds, you should download or update on the stable release channel to Android Studio 2.1.

Android Studio 2.1 includes the following new features:

  • N Developer Preview Support: Android Studio 2.1 is the best IDE to test and validate your app with the N Developer Preview. Get the latest versions of the preview SDK, experiment with the new Java 8 support, and gain access to the only official Android Emulator able to run N Developer Preview Emulator System Images to help in your testing.
  • Instant Run: For those of you who enjoyed the fast edit, build and deploy cycle with Android Studio 2.0, Instant Run now can now update incremental changes to your app code significantly faster.

Deeper Dive into the New Features

N Developer Preview

On top of new features and APIs of the N Developer Preview, Android Studio 2.1 release includes support for the new Jack compiler and support for Java 8. With the Jack compiler, lambdas, method references, compile-time type annotations, intersection types and type inference are available on all versions of the Android platform. Default and static methods and repeatable annotations are available on Android N and higher. To use Java 8 language features when developing with the N Developer Preview, you need to use the Jack compiler. The New Project Wizard [File→ New→ Project] generates the correct configurations for projects targeting the N.

Getting started with development is as easy generating a new project or updating a few settings in your existing project. Once you are ready to test, you can create a fresh Android Virtual Device (AVD) and run your app on the N Developer Preview using the new Android Emulator.


N Developer Preview on the new Android Emulator

Instant Run & General Build Performance Improvements

Instant Run and general build speed are now faster with two new features: incremental Java compilation and in-process dex.

In previous versions of Android Studio, a single line of Java code change will cause all the Java sources in the module to be recompiled. Now in Android Studio 2.1, incremental Java compilation is enabled by default to reduce compilation time by compiling only what is needed.

We are also speeding up build times by using in-process dex, which converts class files to dex files within the Gradle daemon process. This avoids the costly processing operation of creating separate dex processes. To use this feature, you will need to increase the amount of memory available to the Gradle daemon to at least 2GB (1 GB is the default). This feature will help speed up both incremental and full builds.

We’d appreciate your feedback as we continue to improve Instant Run and general build performance. We are going to keep working on making build times even faster in coming releases. Click here to learn even more about the build changes.

What's Next

Update

If you are using a previous version of Android Studio, you can check for updates on the Stable channel from the navigation menu (Help → Check for Update [Windows/Linux] , Android Studio → Check for Updates [OS X]). If you need a new copy of Android Studio, you can download it here.

Test and Validate Apps with N Developer Preview

After you update to or download Android Studio 2.1 and you want to test and develop your apps with the N Developer Preview, create a fresh Android Virtual Device (AVD) for the new Android emulator, and check out these additional setup instructions.

We appreciate any feedback on things you like, issues or features you would like to see. Connect with us -- the Android Studio development team -- on our Google+ page or on Twitter.

Categories: Programming

Protecting against unintentional regressions to cleartext traffic in your Android apps

Mon, 04/25/2016 - 22:30

Posted by Alex Klyubin, Android Security team

When your app communicates with servers using cleartext network traffic, such as HTTP, the traffic risks being eavesdropped upon and tampered with by third parties. This may leak information about your users and open your app up to injection of unauthorized content or exploits. Ideally, your app should use secure traffic only, such as by using HTTPS instead of HTTP. Such traffic is protected against eavesdropping and tampering.

Many Android apps already use secure traffic only. However, some of them occasionally regress to cleartext traffic by accident. For example, an inadvertent change in one of the server components could make the server provide the app with HTTP URLs instead of HTTPS URLs. The app would then proceed to communicate in cleartext, without any user-visible symptoms. This situation may go unnoticed by the app’s developer and users.

Even if you believe your app is only using secure traffic, make sure to use the new mechanisms provided by Android Marshmallow (Android 6.0) to catch and prevent accidental regressions.

New protection mechanisms

For apps which only use secure traffic, Android 6.0 Marshmallow (API Level 23) introduced two mechanisms to address regressions to cleartext traffic: (1) in production / installed base, block cleartext traffic, and (2) during development / QA, log or crash whenever non-TLS/SSL traffic is encountered. The following sections provide more information about these mechanisms.

Block cleartext traffic in production

To protect the installed base of your app against regressions to cleartext traffic, declare android:usesCleartextTraffic=”false” attribute on the application element in your app’s AndroidManifest.xml. This declares that the app is not supposed to use cleartext network traffic and makes the platform network stacks of Android Marshmallow block cleartext traffic in the app. For example, if your app accidentally attempts to sign in the user via a cleartext HTTP request, the request will be blocked and the user’s identity and password will not leak to the network.

You don’t have to set minSdkVersion or targetSdkVersion of your app to 23 (Android Marshmallow) to use android:usesCleartextTraffic. On older platforms, this attribute is simply ignored and thus has no effect.

Please note that WebView does not yet honor this feature.

And under certain circumstances cleartext traffic may still leave or enter the app. For example, Socket API ignores the cleartext policy because it does not know whether the data it transmits or receives can be classified as cleartext. Android platform HTTP stacks, on the other hand, honor the policy because they know whether traffic is cleartext.

Google AdMob is also built to honor this policy. When your app declares that it does not use cleartext traffic, only HTTPS-only ads should be served to the app.

Third-party network, ad, and analytics libraries are encouraged to add support for this policy. They can query the cleartext traffic policy via the NetworkSecurityPolicy class.

Detect cleartext traffic during development

To spot cleartext traffic during development or QA, StrictMode API lets you modify your app to detect non-TLS/SSL traffic and then either log violations to system log or crash the app (see StrictMode.VmPolicy.Builder.detectCleartextNetwork()). This is a useful tool for identifying which bits of the app are using non-TLS/SSL (and DLTS) traffic. Unlike the android:usesCleartextTraffic attribute, this feature is not meant to be enabled in app builds distributed to users.

Firstly, this feature is supposed to flag secure traffic that is not TLS/SSL. More importantly, TLS/SSL traffic via HTTP proxy also may be flagged. This is an issue because as a developer, you have no control over whether a particular user of your app may have configured their Android device to use an HTTP proxy. Finally, the implementation of the feature is not future-proof and thus may reject future TLS/SSL protocol versions. Thus, this feature is intended to be used only during the development and QA phase.

Declare finer-grained cleartext policy in Network Security Config

Android N offers finer-grained control over cleartext traffic policy. As opposed to android:usesCleartextTraffic attribute, which applies to all destinations with which an app communicates, Android N’s Network Security Config lets an app specify cleartext policy for specific destinations. For example, to facilitate a more gradual transition towards a policy that does not allow cleartext traffic, an app can at first block accidental cleartext only for communication with its most important backends and permit cleartext to be used for other destinations.

Next steps

It is a security best practice to only use secure network traffic for communication between your app and its servers. Android Marshmallow enables you to enforce this practice, so give it a try!

As always, we appreciate feedback and welcome suggestions for improving Android. Contact us at security@android.com. HTTPS, Android-Security

Categories: Programming

Build beautifully for Android Wear’s Round Screen using API 23’s -round identifier

Wed, 04/20/2016 - 23:16

Posted by Hoi Lam, Android Wear Developer Advocate

Android Wear is about choice. From the beginning, users could choose the style they wanted, including watches with circular screens. With Android Wear API 23, we have enabled even better developer support so that you can code delightful experiences backed by beautiful code. The key component of this is the new round resource identifier which helps you separate resource files such as layouts, dimens between round and square devices. In this blog post, I will lay out the options that developers have and why you should consider dimens.xml! In addition, I will outline how best to deal with devices which have a chin.

Getting started? Consider BoxInsetLayout!

If all your content can fit into a single square screen, use the BoxInsetLayout. This class has been included in the Wearable Support Library from the start and helps you put all the content into the middle square area of the circular screen and is ignored by square screens. For details on how to use the BoxInsetLayout, refer to the Use a Shape-Aware Layout section in our developer guide.

Without BoxInsetLayout With BoxInsetLayout
Goodbye WatchViewStub, Hello layout-round!

Developers have been able to specify different layouts for square and round watches using WatchViewStub from the beginning. With Android Wear API 23, this has become even easier. Developers can put different layouts into layout-round and layout folders. Previously with WatchViewStub, developers needed to wait until the layout was inflated before attaching view elements, this added significant complexity to the code. This is eliminated using the -round identifier:

 Pre Android Wear API 23 - WatchViewStub (4 files)

pre.CICodeFormatter{ font-family:arial; font-size:12px; border:1px dashed #CCCCCC; width:99%; height:auto; overflow:auto; background:#f0f0f0; line-height:20px; padding:0px; color:#000000; text-align:left; } pre.CICodeFormatter code{ color:#000000; word-wrap:normal; } 1. layout/activity_main.xml
 <?xml version="1.0" encoding="utf-8"?>  
 <android.support.wearable.view.WatchViewStub    
     xmlns:android="http://schemas.android.com/apk/res/android"  
     xmlns:app="http://schemas.android.com/apk/res-auto"  
     xmlns:tools="http://schemas.android.com/tools"  
     android:id="@+id/watch_view_stub"  
     android:layout_width="match_parent"  
     android:layout_height="match_parent"  
     app:rectLayout="@layout/rect_activity_main"  
     app:roundLayout="@layout/round_activity_main"  
     tools:context="com.android.example.watchviewstub.MainActivity"  
     tools:deviceIds="wear"></android.support.wearable.view.WatchViewStub>

2. layout/rect_activity_main.xml - layout for square watches

3. layout/round_activity_main.xml - layout for round watches

4. MainAcitivity.java
  
 protected void onCreate(Bundle savedInstanceState) {  
   super.onCreate(savedInstanceState);  
   setContentView(R.layout.activity_main);  
   final WatchViewStub stub = (WatchViewStub) findViewById(R.id.watch_view_stub);  
   stub.setOnLayoutInflatedListener(new WatchViewStub.OnLayoutInflatedListener() {  
     @Override  
     public void onLayoutInflated(WatchViewStub stub) {  
       mTextView = (TextView) stub.findViewById(R.id.text);  
     }  
   });  
 }  

 After Android Wear API 23 - layout-round (3 files)

1. layout-notround/activity_main.xml - layout for square watches

2. layout-round/activity_main.xml - layout for round watches

3. MainAcitivity.java pre.CICodeFormatter{ font-family:arial; font-size:12px; border:1px dashed #CCCCCC; width:99%; height:auto; overflow:auto; background:#f0f0f0; line-height:20px; padding:0px; color:#000000; text-align:left; } pre.CICodeFormatter code{ color:#000000; word-wrap:normal; }
 protected void onCreate(Bundle savedInstanceState) {  
     super.onCreate(savedInstanceState);  
     setContentView(R.layout.activity_main);  
     mTextView = (TextView) findViewById(R.id.text);    
 }  

That said, since WatchViewStub is part of the Android Wear Support Library, if your current code uses it, it is not a breaking change and you can refactor your code at your convenience. In addition to the -round identifier, developers also use the -notround idenifier to separate resources. So why would you want to use it in place of the default layout? It’s a matter of style. If you have a mixture of layouts, you might consider organising layouts in this way:

  • layout/ - Layouts which works for both circular and square watches
  • layout-round/ and layout-notround/ - Screen shape specific layouts

An even better way to develop for round - values-round/dimens.xml

Maintaining multiple layout files is potentially painful. Each time you add a screen element, you need to go to all the layout files and add this. With mobile devices, you will usually only do this to specify different layouts for phones and tablets and rarely for different phone resolutions. For watches, unless your screen layout is significantly different between round and square (which is rare based on the applications I have seen thus far), you should consider using different dimens.xml instead.

As I experimented with the -round identifier, I found that the easiest way to build for round and square watches is actually by specifying values/dimens.xml and values-round/dimens.xml. By specifying different padding settings, I am able to create the following layout with the same layout.xml file and two dimens files - one for square and one for round. The values used suits this layout, you should experiment with different values to see what works best:

values-round/dimens.xml values/dimens.xml pre.CICodeFormatter{ font-family:arial; font-size:12px; border:1px dashed #CCCCCC; width:99%; height:auto; overflow:auto; background:#f0f0f0; line-height:20px; padding:0px; color:#000000; text-align:left; } pre.CICodeFormatter code{ color:#000000; word-wrap:normal; }
 <dimen name="header_start_padding">36dp</dimen>  
 <dimen name="header_end_padding">22dp</dimen>  
 <dimen name="list_start_padding">36dp</dimen>  
 <dimen name="list_end_padding">22dp</dimen>  
pre.CICodeFormatter{ font-family:arial; font-size:12px; border:1px dashed #CCCCCC; width:99%; height:auto; overflow:auto; background:#f0f0f0; line-height:20px; padding:0px; color:#000000; text-align:left; } pre.CICodeFormatter code{ color:#000000; word-wrap:normal; }
 <dimen name="header_start_padding">16dp</dimen>  
 <dimen name="header_end_padding">16dp</dimen>  
 <dimen name="list_start_padding">10dp</dimen>  
 <dimen name="list_end_padding">10dp</dimen>  

Before API 23, to do the same would have involved a significant amount of boilerplate code manually specifying the different dimensions for all elements on the screen. With the -round identifier, this is now easy to do in API 23 and is my favourite way to build round / square layouts.

Don’t forget the chin!

Some watches have an inset (also know as a “chin”) in an otherwise circular screen. So how should you can you build a beautiful layout while keeping your code elegant? Consider this design:

pre.CICodeFormatter{ font-family:arial; font-size:12px; border:1px dashed #CCCCCC; width:99%; height:auto; overflow:auto; background:#f0f0f0; line-height:20px; padding:0px; color:#000000; text-align:left; } pre.CICodeFormatter code{ color:#000000; word-wrap:normal; }

activity_main.xml

 <FrameLayout  
   ...>  
   <android.support.wearable.view.CircledImageView  
     android:id="@+id/androidbtn"  
     android:src="@drawable/ic_android"  
     .../>  
   <ImageButton  
     android:id="@+id/lovebtn"  
     android:src="@drawable/ic_favourite"  
     android:paddingTop="5dp"  
     android:paddingBottom="5dp"  
     android:layout_gravity="bottom"  
     .../>  
 </FrameLayout>  

If we are to do nothing, the heart shape button will disappear into the chin. Luckily, there’s an easy way to fix this with fitsSystemWindows:

pre.CICodeFormatter{ font-family:arial; font-size:12px; border:1px dashed #CCCCCC; width:99%; height:auto; overflow:auto; background:#f0f0f0; line-height:20px; padding:0px; color:#000000; text-align:left; } pre.CICodeFormatter code{ color:#000000; word-wrap:normal; }
 <ImageButton  
     android:id="@+id/lovebtn"  
     android:src="@drawable/ic_favourite"  
     android:paddingTop="5dp"  
     android:paddingBottom="5dp"  
    android:fitsSystemWindows="true"  
     .../>  

For the eagle-eyed (middle image of the screen shown below under “fitsSystemWindows=”true””), you might noticed that the top and bottom padding that we have put in is lost. This is one of the main side effect of using fitsSystemWindows. This is because fitsSystemWindows works by overriding the padding to make it fits the system window. So how do we fix this? We can replace padding with InsetDrawables:

inset_favourite.xml

pre.CICodeFormatter{ font-family:arial; font-size:12px; border:1px dashed #CCCCCC; width:99%; height:auto; overflow:auto; background:#f0f0f0; line-height:20px; padding:0px; color:#000000; text-align:left; } pre.CICodeFormatter code{ color:#000000; word-wrap:normal; }
 <inset  
   xmlns:android="http://schemas.android.com/apk/res/android"  
   android:drawable="@drawable/ic_favourite"
   android:insetTop="5dp"  
   android:insetBottom="5dp"
/>  

activity_main.xml

pre.CICodeFormatter{ font-family:arial; font-size:12px; border:1px dashed #CCCCCC; width:99%; height:auto; overflow:auto; background:#f0f0f0; line-height:20px; padding:0px; color:#000000; text-align:left; } pre.CICodeFormatter code{ color:#000000; word-wrap:normal; }
 <ImageButton  
     android:id="@+id/lovebtn"  
     android:src="@drawable/inset_favourite"  
     android:paddingTop="5dp"  
     android:paddingBottom="5dp"  
     android:fitsSystemWindows="true"  
     .../>  

Although the padding setting in the layout will be ignored, the code is tidier if we remove this redundant code.

Do nothing fitsSystemWindows=”true” fitsSystemWindows=”true”
and use InsetDrawable

If you require more control than what is possible declaratively using xml, you can also programmatically adjust your layout. To obtain the size of the chin you should attach a View.OnApplyWindowInsetsListener to the outermost view of your layout. Also don’t forget to call v.onApplyWindowInsets(insets). Otherwise, the new listener will consume the inset and inner elements which react to insets may not react.

How to obtain the screen chin size programmatically

MainActivity.java

pre.CICodeFormatter{ font-family:arial; font-size:12px; border:1px dashed #CCCCCC; width:99%; height:auto; overflow:auto; background:#f0f0f0; line-height:20px; padding:0px; color:#000000; text-align:left; } pre.CICodeFormatter code{ color:#000000; word-wrap:normal; }
 private int mChinSize;  
 protected void onCreate(Bundle savedInstanceState) {  
     super.onCreate(savedInstanceState);  
     setContentView(R.layout.activity_main);  
     // find the outermost element  
     final View container = findViewById(R.id.outer_container);  
     // attach a View.OnApplyWindowInsetsListener  
     container.setOnApplyWindowInsetsListener(new View.OnApplyWindowInsetsListener() {  
         @Override  
         public WindowInsets onApplyWindowInsets(View v, WindowInsets insets) {  
             mChinSize = insets.getSystemWindowInsetBottom();  
             // The following line is important for inner elements which react to insets  
             v.onApplyWindowInsets(insets);

             return insets;  
     }  
   });  
 }  

Last but not least, remember to test your code! Since last year, we have included several device images for Android Wear devices with a chin to make testing easier and faster:

Square peg in a round hole no more!

Android Wear has always been about empowering users to wear what they want. A major part in enabling this is the round screen. With API 23 and the -round resource identifier, it is easier than ever to build for both round and square watches - delightful experiences backed by beautiful code!

Additional Resources

Why would I want to fitsSystemWindows? by Ian Lake - Best practice for using this powerful tool including its limitations. ScreenInfo Utility by Wayne Piekarski - Get useful information for your display including DPI, chin size, etc.

Categories: Programming

Deprecation of BIND_LISTENER with Android Wear APIs

Wed, 04/20/2016 - 22:26

Posted by Wayne Piekarski, Developer Advocate, Android Wear

If you’re an Android Wear developer, we wanted to let you know of a change you might need to make to your app to improve the performance of your user’s devices. If your app is using BIND_LISTENER intent filters in your manifest, it is important that you are aware that this API has been deprecated on all Android versions. The new replacement API introduced in Google Play Services 8.2 is more efficient for Android devices, so developers are encouraged to migrate to this as soon as possible to ensure the best user experience. It is important that all Android Wear developers are aware of this change and update their apps as soon as possible.

Limitations of BIND_LISTENER API

When Android Wear introduced the WearableListenerService, it allowed you to listen to changes via the BIND_LISTENER intent filter in the AndroidManifest.xml. These changes included data item changes, message arrivals, capability changes, and peer connects/disconnects.

The WearableListenerService starts whenever any of these events occur, even if the app is only interested in one type. When a phone has a large number of apps using WearableListenerService and BIND_LISTENER, a watch appearing or disappearing can cause many services to start up. This applies memory pressure to the device, causing other activities and services to be shut down, and generates unnecessary work.

Fine-grained intent filter API

In Google Play Services 8.2, we introduced a new fine-grained intent filter mechanism that allows developers to specify exactly what events they are interested in. For example, if you have multiple listener services, use a path prefix to filter only those data items and messages meant for the service, with syntax like this:


 <service android:name=".FirstExampleService">  
   <intent-filter>  
       <action android:name="com.google.android.gms.wearable.DATA_CHANGED" />  
       <action android:name="com.google.android.gms.wearable.MESSAGE_RECEIVED" />  
       <data android:scheme="wear" android:host="*" android:pathPrefix="/FirstExample" />  
   </intent-filter>  
 </service>  

There are intent filters for DATA_CHANGED, MESSAGE_RECEIVED, CHANNEL_EVENT, and CAPABILITY_CHANGED. You can specify multiple elements, and if any of them match, it will call your service and filter out anything else. If you do not include a element, all events will be filtered out and your service will never be called, so make sure to include at least one. You should be aware that registering in an AndroidManifest.xml for CAPABILITY_CHANGED will cause your service to be called any time a device advertising this capability appears or disappears, so you should use this only if there is a compelling reason.

Live listeners

If you only need these events when an Activity or Service is running, then there is no need to register a listener in AndroidManifest.xml at all. Instead, you can use addListener() live listeners, which will only be active when the Activity or Service is running, and will not impact the device otherwise. This is particularly useful if you want to do live status updates for capabilities being available in an Activity, but with no further background impact. In general, you should try to use addListener(), and only use AndroidManifest.xml when you need to receive events all the time.

Best practices

In general, you should only use a listener in AndroidManifest.xml for events that must launch your service. For example, if your watch app needs to send an interactive message or data to the phone.

You should try to limit the number of wake-ups of your service by using filters. If most of the events do not need to launch your app, then use a path and a filter that only matches the event you need. This is critical to limit the number of launches of your service.

If you have other cases where you do not need to launch a service, such as listening for status updates in an Activity, then register a live listener only for the duration it is needed.

Documentation

There is more information available about Data Layer events and the use of WearableListenerService, and tags in the manifest. Android Studio has a guide with a summary of how to convert to the new API. The Android Wear samples also show best practices in the use of WearableListenerService, such as DataLayer and XYZTouristAttractions. The changes needed are very small, and can be seen in this git diff from one of the samples here.

Removal of BIND_LISTENER

With the release of Android Studio 2.1, lint rules have been added that flag the use of BIND_LISTENER as a fatal error, and developers will need to make a small change to the AndroidManifest.xml to declare accurate intent filters. If you are still using BIND_LISTENER, you will receive the following error:

 AndroidManifest.xml:11: Error: The com.google.android.gms.wearable.BIND_LISTENER action is deprecated. [WearableBindListener]  
          <action android:name="com.google.android.gms.wearable.BIND_LISTENER" />  
              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  

This will only impact developers who are recompiling their apps with Android Studio 2.1 and will not affect existing apps on user’s devices.

For developers who are using Google Play Services earlier than 8.2, the lint rules will not generate an error, but you should update to a newer version and implement more accurate intent filters as soon as possible.

In order to give users the best experience, we plan to disable BIND_LISTENER in the near future. It is therefore important that developers take action now, to avoid any future disruption experienced by users of their apps.

Categories: Programming

Optimize, Develop, and Debug with Vulkan Developer Tools

Fri, 04/15/2016 - 10:30

Posted by Shannon Woods, Technical Program Manager

Today we're pleased to bring you a preview of Android development tools for Vulkan™. Vulkan is a new 3D rendering API which we’ve helped to develop as a member of Khronos, geared at providing explicit, low-overhead GPU (Graphics Processor Unit) control to developers. Vulkan’s reduction of CPU overhead allows some synthetic benchmarks to see as much as 10 times the draw call throughput on a single core as compared to OpenGL ES. Combined with a threading-friendly API design which allows multiple cores to be used in parallel with high efficiency, this offers a significant boost in performance for draw-call heavy applications.

Vulkan support is available now via the Android N Preview on devices which support it, including Nexus 5X and Nexus 6P. (Of course, you will still be able to use OpenGL ES as well!)

To help developers start coding quickly, we’ve put together a set of samples and guides that illustrate how to use Vulkan effectively.

You can see Vulkan in action running on an Android device with Robert Hodgin’s Fish Tornado demo, ported by Google’s Art, Copy, and Code team:


Optimization: The Vulkan API

There are many similarities between OpenGL ES and Vulkan, but Vulkan offers new features for developers who need to make every millisecond count.

  • Application control of memory allocation. Vulkan provides mechanisms for fine-grained control of how and when memory is allocated on the GPU. This allows developers to use their own allocation and recycling policies to fit their application, ultimately reducing execution and memory overhead and allowing applications to control when expensive allocations occur.
  • Asynchronous command generation. In OpenGL ES, draw calls are issued to the GPU as soon as the application calls them. In Vulkan, the application instead submits draw calls to command buffers, which allows the work of forming and recording the draw call to be separated from the act of issuing it to the GPU. By spreading command generation across several threads, applications can more effectively make use of multiple CPU cores. These command buffers can also be reused, reducing the overhead involved in command creation and issuance.
  • No hidden work. One OpenGL ES pitfall is that some commands may trigger work at points which are not explicitly spelled out in the API specification or made obvious to the developer. Vulkan makes performance more predictable and consistent by specifying which commands will explicitly trigger work and which will not.
  • Multithreaded design, from the ground up. All OpenGL ES applications must issue commands for a context only from a single thread in order to render predictably and correctly. By contrast, Vulkan doesn’t have this requirement, allowing applications to do work like command buffer generation in parallel— but at the same time, it doesn’t make implicit guarantees about the safety of modifying and reading data from multiple threads at the same time. The power and responsibility of managing thread synchronization is in the hands of the application.
  • Mobile-friendly features. Vulkan includes features particularly helpful for achieving high performance on tiling GPUs, used by many mobile devices. Applications can provide information about the interaction between separate rendering passes, allowing tiling GPUs to make effective use of limited memory bandwidth, and avoid performing off-chip reads.
  • Offline shader compilation. Vulkan mandates support for SPIR-V, an intermediate language for shaders. This allows developers to compile shaders ahead of time, and ship SPIR-V binaries with their applications. These binaries are simpler to parse than high-level languages like GLSL, which means less variance in how drivers perform this parsing. SPIR-V also opens the door for third parties to provide compilers for specialized or cross-platform shading languages.
  • Optional validation. OpenGL ES validates every command you call, checking that arguments are within expected ranges, and objects are in the correct state to be operated upon. Vulkan doesn’t perform any of this validation itself. Instead, developers can use optional debug tools to ensure their calls are correct, incurring no run-time overhead in the final product.

Debugging: Validation Layers

As noted above, Vulkan’s lack of implicit validation requires developers to make use of tools outside the API in order to validate their code. Vulkan’s layer mechanism allows validation code and other developer tools to inspect every API call during development, without incurring any overhead in the shipping version. Our guides show you how to build the validation layers for use with the Android NDK, giving you the tools necessary to build bug-free Vulkan code from start to finish.


Develop: Shader toolchain
The Shaderc collection of tools provides developers with build-time and run-time tools for compiling GLSL into SPIR-V. Shaders can be compiled at build time using glslc, a command-line compiler, for easy integration into existing build systems. Or, for shaders which are generated or edited during execution, developers can use the Shaderc library to compile GLSL shaders to SPIR-V via a C interface. Both tools are built on top of Khronos’s reference compiler.


Additional Resources

The Vulkan ecosystem is a broad one, and the resources to get you started don’t end here. There is a wealth of material to explore, including:

Categories: Programming

Android Studio 2.0

Fri, 04/15/2016 - 04:54

Posted by Jamal Eason, Product Manager, Android

Android Studio 2.0 is the fastest way to build high quality, performant apps for the Android platform, including phones and tablets, Android Auto, Android Wear, and Android TV. As the official IDE from Google, Android Studio includes everything you need to build an app, including a code editor, code analysis tools, emulators and more. This new and stable version of Android Studio has fast build speeds and a fast emulator with support for the latest Android version and Google Play Services.

Android Studio is built in coordination with the Android platform and supports all of the latest and greatest APIs. If you are developing for Android, you should be using Android Studio 2.0. It is available today as a easy download or update on the stable release channel.

Android Studio 2.0 includes the following new features that Android developer can use in their workflow :

  • Instant Run - For every developer who loves faster build speeds. Make changes and see them appear live in your running app. With many build/run accelerations ranging from VM hot swapping to warm swapping app resources, Instant Run will save you time every day.
  • Android Emulator - The new emulator runs ~3x faster than Android’s previous emulator, and with ADB enhancements you can now push apps and data 10x faster to the emulator than to a physical device. Like a physical device, the official Android emulator also includes Google Play Services built-in, so you can test out more API functionality. Finally, the new emulator has rich new features to manage calls, battery, network, GPS, and more.
  • Cloud Test Lab Integration - Write once, run anywhere. Improve the quality of your apps by quickly and easily testing on a wide range of physical Android devices in the Cloud Test Lab right from within Android Studio.
  • App Indexing Code Generation & Test - Help promote the visibility your app in Google Search for your users by adding auto-generated URLS with the App Indexing feature in Android Studio. With a few click you can add indexable URL links that you can test all within the IDE.
  • GPU Debugger Preview - For those of you developing OpenGL ES based games or apps, you can now see each frame and the GL state with the new GPU debugger. Uncover and diagnosis GL rendering issues by capturing and analyzing the GPU stream from your Android device.
  • IntelliJ 15 Update - Android Studio is built on the world class Intellij coding platform. Check out the latest Intellij features here.

Deeper Dive into the New Features

Instant Run

Today, mobile platforms are centered around speed and agility. And yet, building for mobile can sometimes feel clunky and slow. Instant Run in Android Studio is our solution to keep you in a fast and fluid development flow. The feature increases your developer productivity by accelerating your edit, build, run cycles. When you click on the Instant Run button (), Instant Run will analyze the changes you have made and determine how it can deploy your new code in the fastest way.

New Instant Run Buttons

Whenever possible, it will inject your code changes into your running app process, avoiding re-deployment and re-installation your APK. For some types of changes, an activity or app restart is required, but your edit, build and run cycles should still be generally much faster than before. Instant Run works with any Android Device or emulator running API 14 (Ice Cream Sandwich) or higher.

Since previewing Instant Run at the end of last year, we’ve spent countless hours incorporating your feedback and refining for the stable release. Look for even more acceleration in future releases because build speeds can never be too fast. To learn how you can make the most out of Instant Run in your app development today, please check out our Instant Run documentation.

Android Emulator

The new Android Emulator is up to 3x faster in CPU, RAM, & I/O in comparison to the previous Android emulator. And when you're ready to build, ADB push speeds are a whopping 10x faster! In most situations, developing on the official Android Emulator is faster than a real device, and new features like Instant Run will work best with the new Android emulator.

In addition to speed and performance, the Android Emulator has a brand user interface and sensor controls. Enhanced since the initial release, with the emulator you can drag and drop APKs for quick installation, resize and rescale the window, use multi-touch actions (pinch & zoom, pan, rotate, tilt) and much more.

Android Emulator User Interface: Toolbar & Extend Controls Panel

Trying out the new emulator is as easy as updating your SDK Tools to 25.1.1 or higher, create a fresh Android Virtual Device using one of the recommended x86 system images and you are ready to go. Learn more about the Android Emulator by checking out the documentation.

Cloud Test Lab

Cloud Test Lab is a new service that allows you to test your app across a wide range of devices and device configurations at scale in the cloud. Once you complete your initial testing with your Android Emulator or Android device, Cloud Test Lab is a great extension to your testing process that provides you to run through a collection of tests against a portfolio of physical devices hosted in Google’s data centers. Even if you do not have tests explicitly written, Cloud Test Lab can perform a basic set of tests to ensure that your app does not crash.

The new interface in Android Studio allows you to configure the portfolio of tests you want to run on Cloud Test Lab, and allows you to also see the results of your tests. To learn more about the service go here.

Setup for Cloud Test Lab

App Indexing

It is now easier for your users to find your app in Google Search with the App Indexing API. Android Studio 2.0 helps you to create the correct URL structure in your app code and add attributes in your AndroidManifest.xml file that will work the Google App Indexing service. After you add the URLs to your app, can you test and validate your app indexing code as shown here:

Google App Indexing Testing

Check out this link for more details about app indexing support in Android Studio.

GPU Debugger Preview

If you are developing OpenGL ES games or graphics-intensive apps, you have a new GPU debugger with Android Studio 2.0. Although the GPU debugger is a preview, you can step through your app frame by frame to identify and debug graphics rendering issues with rich information about the GL state. For more details on how to setup your Android device and app to work with the tool, check out the tech documentations here.

GPU Debugger Preview

What's Next

Update

If you are using a previous version of Android Studio, you can check for updates on the Beta channel from the navigation menu (Help → Check for Update [Windows/Linux] , Android Studio → Check for Updates [OS X]). If you need a new copy of Android Studio, you can download it here. If you developing for the N Developer Preview, check out this additional setup instructions.

Set Up Instant Run & Android Emulator

After you update to or download Android Studio 2.0, you should upgrade your projects to use Instant Run, and create a fresh Android Virtual Device (AVD) for the new Android emulator and you are on your way to a fast Android development experience.

Using Instant Run is easy. For each of your existing projects you will see a quick prompt to update your project to the new gradle plugin version (com.android.tools.build:gradle:2.0.0).

Prompt to update your gradle version in your project

For all new app projects in Android Studio 2.0, Instant Run is on by default. Check out the documentation for more details.

We are already hard at work developing the next release of Android Studio. We appreciate any feedback on things you like, issues or features you would like to see. Connect with us -- the Android Studio development team -- on our new Google+ page or on Twitter.

Categories: Programming

Android N Developer Preview 2, out today!

Fri, 04/15/2016 - 04:49

Posted by Dave Burke, VP of Engineering

Last month, we released the first Developer Preview of Android N, to give you a sneak peek at our next platform. The feedback you’ve shared to-date has helped us catch bugs and improve features. Today, the second release in our series of Developer Previews is ready for you to continue testing against your apps.

This latest preview of Android N fixes a few bugs you helped us identify, such as not being able to connect to hidden Wi-Fi networks (AOSP 203116), Multiwindow pauses (AOSP 203424), and Direct Reply closing an open activity (AOSP 204411), to name just a few. We’re still on the hunt for more; please continue to share feedback, either in the N Developer Preview issue tracker or in the N preview community.


What’s new:

Last month’s Developer Preview introduced a host of new features, like Multi-window, bundled notifications and more. This preview builds on those and includes a few new ones:

  • Vulkan: Vulkan is a new 3D rendering API which we’ve helped to develop as a member of Khronos, geared at providing explicit, low-overhead GPU (Graphics Processor Unit) control to developers and offers a significant boost in performance for draw-call heavy applications. Vulkan’s reduction of CPU overhead allows some synthetic benchmarks to see as much as 10 times the draw-call throughput on a single core as compared to OpenGL ES. Combined with a threading-friendly API design which allows multiple cores to be used in parallel with high efficiency, this offers a significant boost in performance for draw-call heavy applications. With Android N, we’ve made Vulkan a part of the platform; you can try it out on supported devices running Developer Preview 2. Read more here. Vulkan Developer Tools blog here.
  • Launcher shortcuts: Now, apps can define shortcuts which users can expose in the launcher to help them perform actions quicker. These shortcuts contain an Intent into specific points within your app (like sending a message to your best friend, navigating home in a mapping app, or playing the next episode of a TV show in a media app).

    An application can publish shortcuts with ShortcutManager.setDynamicShortcuts(List) and ShortcutManager.addDynamicShortcut(ShortcutInfo), and launchers can be expected to show 3-5 shortcuts for a given app.

  • Emoji Unicode 9 support: We are introducing a new emoji design for people emoji that moves away from our generic look in favor of a more human-looking design. If you’re a keyboard or messaging app developer, you should start incorporating these emoji into your apps. The update also introduces support for skin tone variations and Unicode 9 glyphs, like the bacon, selfie and face palm. You can dynamically check for the new emoji characters using Paint.hasGlyph().

New human emoji

New activity emoji

  • API changes: This update includes API changes as we continue to refine features such as multi-window support (you can now specify a separate minimum height and minimum width for an activity), notifications, and others. For details, take a look at the diff reports available in the downloadable API reference package.

  • Bug fixes: We’ve resolved a number of issues throughout the system, including these fixes for issues that you’ve reported through the public issue tracker. Please continue to let us know what you find and follow along with the known issues here.

How to get the update:

The easiest way to get this and later preview updates is by enrolling your devices in the Android Beta Program. Just visit g.co/androidbeta and opt-in your eligible Android phone or tablet -- you’ll soon receive this (and later) preview updates over-the-air. If you’ve already enrolled your device, you’ll receive the update shortly, no action is needed on your part. You can also download and flash this update manually. Developer Preview 2 is intended for developers and not as a daily driver; this build is not yet optimized for performance and battery life.

The N Developer Preview is currently available for Nexus 6, Nexus 5X, Nexus 6P, Nexus 9, and Pixel C devices, as well as General Mobile 4G [Android One] devices. For Nexus Player, the update to Developer Preview 2 will follow the other devices by several days.

To build and test apps with Developer Preview 2, you need to use Android Studio 2.1 -- the same version that was required for Developer Preview 1. You’ll need to check for SDK components updates (including build tools and emulator system images) for Developer Preview 2 -- see here for details.

Thanks so much for all of your feedback so far. Please continue to share feedback, either in the N Developer Preview issue tracker or in the N preview community. The sooner we’re able to get your feedback, the more of of it we will be able to incorporate in the next release of Android.

Categories: Programming

Android Developer Story: Video editing app WeVideo increases user engagement with material design

Wed, 04/06/2016 - 17:36

Posted by Lily Sheringham, Google Play team

WeVideo is a video editing platform founded on a vision to make video creation accessible to anyone, anywhere. They first launched the popular WeVideo Video Editor app for Android, and since the latest update to the app, revenue on the platform has doubled every two months. In fact, almost 85% of their mobile users are on Android devices.

Watch Krishna Menon, President & CTO, and Oleg Tsaregorodtsev, Head of Mobile Development at WeVideo, explain how relaunching their app with material design increased user engagement by 100%. They also share how WeVideo improved monetization and installs using ratings & reviews, store listing experiments, and other features on Google Play.

Find out more about material design principles, and, learn how to find success on Google Play.

Categories: Programming

A new method to measure touch and audio latency

Mon, 04/04/2016 - 21:01

Posted by Mark Koudritsky, software engineer

There is a new addition in the arsenal of instruments used by Android and ChromeOS teams in the battle to measure and minimize touch and audio latency: the WALT Latency Timer.

When you use a mobile device, you expect it to respond instantly to your touch or voice: the more immediate the response, the more you feel directly connected to the device. Over the past few years, we have been trying to measure, understand, and reduce latency in our Chromebook and Android products.

Before we can reduce latency, we must first understand where it comes from. In the case of tapping a touchscreen, the time for a response includes the touch-sensing hardware and driver, the application, and the display and graphics output. For a voice command, there is time spent in sampling input audio, the application, and in audio output. Sometimes we have a mixture of these (for example, a piano app would include touch input and audio output).

Most previous work to study latency has focused on measuring a single round-trip latency number. For example, to measure audio latency, an app would measure time from app to speaker/mic and back to the app using the Dr. Rick O'Rang loopback audio dongle together with an appropriate app such as the Dr Rick O’Rang Loopback app or Superpowered Mobile Audio Latency Test App. Similarly, the TouchBot uses a fast camera to measure the round-trip delay from physical touch until a change on the screen is visible. While valuable, the problem with such a setup is that it’s very difficult to break down the latency into input vs output components.

An important innovation in WALT (a descendant of QuickStep) is that it synchronizes an external hardware clock with the Android device or Chromebook to within a millisecond. This allows it to measure input and output latencies separately as opposed to measuring a round-trip latency.

WALT is simple. The parts cost less than $50 and with some basic hobby electronics skills, you can build it yourself.

We’ve been using WALT within Google for Nexus and Chromebook development. We’re now opening this tool to app developers and anyone who wants to precisely measure real-world latencies. We hope that having readily accessible tools will help the industry as a whole improve and make all our devices more responsive to touch and voice.

Categories: Programming