Tag Archives: Android SDK

Peloton increased its multi-device support and saw an uptick in user engagement

Posted by the Android team

The Peloton App makes it easy for people to work out wherever they want, whenever they want. From living room yoga classes to guided audio runs outdoors, Peloton strives to create an engaging exercise experience that works for anyone, anywhere.

For Peloton, creating convenient workouts means making the Peloton App more accessible across surfaces. So after receiving numerous requests to upgrade its Android app experience from its community, along with the Pixel Watch announcement at Google I/O in 2022, the Peloton team saw an opportunity to boost the app’s support across the entire Android ecosystem, ensuring its Members receive a seamless Peloton experience on all their devices.
Quote card with text reads, 'We want to meet Members where they are and on all the devices they own'- Stefan Haaker, senior Android engineer at Peloton. Peloton logo.

Building the Wear OS experience

Peloton developers began updating the app’s multi-device support by creating a modern watch application for Wear OS devices using Compose for Wear OS. With the Compose toolkit, Peloton developers were able to quickly build a watch experience that met Wear OS guidelines. “The Wear OS app was our first usage of Compose in production,” said Stefan Haacker, a senior Android engineer at Peloton. “We really enjoyed how much more productive it made us.”

The Peloton team released the first wearable app version just after the Pixel Watch launched. They worked tirelessly to get the app ready between the announcement of the Pixel Watch and its launch. Thanks to the Jetpack Compose toolkit, Peloton developers were able to rapidly and efficiently prepare the app in record time.

The new wearable app gave Peloton Members more options for monitoring their heart rate in real time. Using the Data Layer API to synchronize information between wearables and the Peloton App, Members can now view their heart rate across devices—from their phones to their watches to their bikes—as they take a Peloton class.

“Before the Wear OS app was released, only a small percentage of Android Members worked out with a heart rate monitor (HRM). After releasing Peloton on Wear OS, the app had a 6X increase in HRM usage in just a few months,” said Stefan. “For Peloton, HRM usage correlates with a better user experience, increased user engagement, and more workouts a month.”

With more Members tracking their health and fitness data through the new Peloton app, it was important for the Peloton team to give them better access to that data. That’s why Peloton was excited to partner with Google to offer Health Connect integration from day one, giving its users a simpler way to consolidate and share their fitness data across applications.

Increased support across devices

Peloton developers wanted to embrace the uniqueness of each device across the Android ecosystem and focus on the individual benefits that their form factors could offer. With this mindset, it was easier for the Peloton team to create a flexible UI that could adapt to various screens.

“We had to stop developing and designing with rigid device categories in mind,” said Ward Bonnefond, a senior staff software engineer at Peloton. “Phones these days no longer have just a single rectangular screen.”

The Peloton team began optimizing for large screens and foldables by improving how the app handles window resizing across orientations and devices. Using resizable emulators, Peloton developers were able to ensure the app behaved as expected with different configurations and screen sizes.

“We used RecyclerViews to determine the number of columns the app displays at runtime based on the available screen size,” said Ward. “We removed restrictions on activity resizing and orientation locking so that our app would function properly in full screen, split screen, resizable floating windows, and foldables.”

Peloton developers used Jetpack WindowManager to support foldable-specific use cases, like tabletop mode for the app’s video player. The window manager library made it easy for developers to place a video above a device’s fold and workout metrics below it.

Peloton developers also streamlined the login process on Android TV. Instead of forcing Members to fumble over typing their credentials with a remote, they can now login through the Peloton App on their phone to quickly connect with their TV.

Quote card with text reads, 'With the Android SDK and Jetpack Libraries, it’s really easy to create a flexible UI that adapts to the different screen size.' — Ward Bonnefond, senior staff software engineer at Peloton

More devices, more opportunities

Since launching the all-new Wear OS application and enhancing support across Android devices, Peloton has seen an uptick in total workouts taken on the Android platform. Although other factors were at play, the Peloton team attributes much of that increase to the new wearable application.

“There are so many different devices with varying capabilities in the Android ecosystem, like phones, watches, tablets, TVs and more,” said Ward. “At the end of the day, we want the Peloton App to be awesome wherever Members use it.”

Get started

Learn how you can start developing for Wear OS and other Android devices today.

Extending the Android SDK

Posted by Anton Hansson, Software EngineerAndroid 10 and higher support Modular System Components that allow us to expedite functional and security updates to the Android ecosystem outside of major API level releases and make new functionality backward compatible on already-released Android versions. These improvements help make development more flexible and broaden the reach for app developers. We've built a new Extension SDK framework for you to integrate with these APIs, and today, we’re releasing the first public version of the Extension SDK (Extension Level 4).

Faster API and feature introductions

Having the ability to introduce new functionality outside of major API level releases allows faster innovations. As shared in a previous post, beginning this year we plan to roll out the initial Privacy Sandbox on Android Beta release to Android 13 devices. You can start using the Extension SDK to integrate your solutions with the AdServices APIs to prepare for limited production testing. Learn more on how to participate in the Privacy Sandbox Beta release, and set up your development environment with a test device or emulator.

Backward compatibility

Extension SDKs also allow us to extend the support of certain platform functionality to existing Android versions, increasing user reach. For example, the PhotoPicker APIs previously available only on API level 33 (Android T) and above are now also available all the way back to API level 30 (Android R) through the Extension SDK on devices with an R extension version of at least 2.
Moving image showing Photopicker API in action on a cellphone screen

Check for API availability

To help you identify extension API availability, we’ve added additional information to the API reference that indicates for which API levels and the minimum extension versions that the API is available. For example, the API reference for ACTION_PICK_IMAGES indicates its availability on “Android R Extensions version 2” and above.
Action_Pick_Images link Added in API level 33 Also in R Extensions 2
You can query the extension version at runtime in a similar way to how Build.VERSION.SDK_INT is commonly used to check for the Android version. For example, if you need to verify the availability of the PhotoPicker APIs, use the new API SdkExtensions.getExtensionVersion. For the R extensions, the version code (30) that corresponds to R is used:
fun isPhotoPickerAvailable(): Boolean { return SdkExtensions.getExtensionVersion(VERSION_CODES.R) >= 2 }

The alternative check, via Build.VERSION.SDK_INT, would look like this:

fun isPhotoPickerAvailable(): Boolean { return Build.VERSION.SDK_INT >= 33 }

This check is still safe and correct, but this function would return false on some devices where the API is now available. As a result, the SDK_INT check is not optimal, and the extension version check is a better way to check for API availability. All devices with SDK_INT >= 33 also have an R extension version of >= 2, but there are devices with SDK_INT < 33 with R extension versions >= 2.

Similarly, the AdServices API reference may indicate that it’s “added in Ad Services Extensions 4”. The Ad Services extension uses the SdkExtensions.AD_SERVICES constant. The availability check looks like this:

fun isAdServicesAvailable(): Boolean { return SdkExtensions.getExtensionVersion(SdkExtensions.AD_SERVICES) >= 4 }

For developer convenience, we are extending Jetpack to make it easier to work with extension versions. For example, you can use a Jetpack library function to check for PhotoPicker availability, which abstracts away the conditional version checks. We expect to be releasing more Jetpack libraries (such as the Privacy Preserving APIs in the Privacy Sandbox) to aid the correct use of APIs released via Extension SDKs.

Tooling support

To help ensure app quality, we added Extension versions tooling support to Android Lint's NewApi check. Since Android Studio Flamingo, it can auto-generate the correct version checks for APIs that have been launched via SDK extensions. Using these new version checks is completely optional, but adopting them could help lead to more widespread use of new APIs when they exist.
Screen grab of version check in use

Get familiarized with SDK extensions

We’re just beginning the SDK Extension developer journey and plan to make more features available in the future. You can get the latest SDK extension 4 available in the SDK Manager today. Learn more about the SDK Extensions and our documentation on the Privacy Sandbox Beta and the photo picker.

An Update on non-SDK restrictions in Android P

Posted by David Brazdil and Nicolas Geoffray, Software Engineers

In Android, we care immensely about providing the best experience to our users and our developers. With each OS release, new features enable you to provide amazing experiences for users; however, we noticed that some app developers have been using non-SDK interfaces, which leads to increased crashes for users and emergency rollouts for developers. We want to do better and need your help to ensure that Android is stable with each new OS.

Three months ago, we announced our plans to start restricting the usage of non-SDK interfaces in Android P. We know these restrictions can impact your release workflow, and we want to make sure you have the tools to detect usage of non-SDK interfaces, as well as time in your planning for adjusting to the new policies and for giving us feedback.

In the Developer Preview and Beta 1, we have provided ways for you to see the impact of these restrictions on your app. In the Developer Preview, use of restricted APIs show up in logs and toast messages, and in Beta 1, we provided a StrictMode policy that allows you to programmatically find these restrictions and do your own logging. For example:

We understand there can be multiple reasons apps want to use non-SDK interfaces, and ensuring your app will continue to work in Android P is important to us. Many of you have explained your use cases through our issue tracker (thank you!), and for most of these requests, we have lifted the restrictions on specific non-SDK interfaces for Android P by adding them to the greylist. In addition, our team has conducted static analysis on millions of apps and processed thousands of automated reports from internal and external beta testers. Through this analysis, we have identified additional non-SDK interfaces that apps rely on and added them to the greylist. For everything on the greylist, we will be investigating public SDK alternatives for future releases. However, it's possible we may have missed some non-SDK interface uses, so we have made the majority of them available for apps whose target SDK is Android Oreo or below.

In summary, apps running on Android P will be subject to restricted usage of non-SDK interfaces. If you are targeting Android P, the greylist shows the non-SDK interfaces that will still be available, while all other non-SDK interfaces will not be accessible. If you are targeting Android Oreo or below, most restrictions will not apply, but you will get logcat warnings if you are accessing non-SDK interfaces that are not in the greylist (note that users don't see such warnings).

Try out our new Beta 2 release and use StrictMode to detect your non-SDK interfaces usage. You should expect Beta 2 to closely match what the final release will implement for restricting non-SDK interface usages. Also, please take a look at our new FAQ, which we hope will answer any questions you have around the feature. If not, let us know!

Spatial audio comes to the Cardboard SDK

Originally posted on Google Developers Blog

Posted by Nathan Martz, Product Manager, Google Cardboard

Human beings experience sound in all directions—like when a fire truck zooms by, or when an airplane is overhead. Starting today, the Cardboard SDKs for Unity and Android support spatial audio, so you can create equally immersive audio experiences in your virtual reality (VR) apps. All your users need is their smartphone, a regular pair of headphones, and a Google Cardboard viewer.

Sound the way you hear it

Many apps create simple versions of spatial audio—by playing sounds from the left and right in separate speakers. But with today’s SDK updates, your app can produce sound the same way humans actually hear it. For example:

  • The SDK combines the physiology of a listener’s head with the positions of virtual sound sources to determine what users hear. For example: sounds that come from the right will reach a user’s left ear with a slight delay, and with fewer high frequency elements (which are normally dampened by the skull).
  • The SDK lets you specify the size and material of your virtual environment, both of which contribute to the quality of a given sound. So you can make a conversation in a tight spaceship sound very different than one in a large, underground (and still virtual) cave.

Optimized for today’s smartphones

We built today’s updates with performance in mind, so adding spatial audio to your app has minimal impact on the primary CPU (where your app does most of its work). We achieve these results in a couple of ways:

  • The SDK is optimized for mobile CPUs (e.g. SIMD instructions) and actually computes the audio in real-time on a separate thread, so most of the processing takes place outside of the primary CPU.
  • The SDK allows you to control the fidelity of each sound. As a result, you can allocate more processing power to critical sounds, while de-emphasizing others.

Simple, native integrations

It’s really easy to get started with the SDK’s new audio features. Unity developers will find a comprehensive set of components for creating soundscapes on Android, iOS, Windows and OS X. And native Android developers will now have a simple Java API for simulating virtual sounds and environments.


Experience spatial audio in our sample app for developers

Check out our Android sample app (for developer reference only), browse the documentation on the Cardboard developers site, and start experimenting with spatial audio today. We’re excited to see (and hear) the new experiences you’ll create!

Android 5.1 Lollipop SDK

By Jamal Eason, Product Manager, Android

Yesterday we announced Android 5.1, an updated version of the Android Lollipop platform that improves stability, provides better control of notifications, and increases performance. As a part of the Lollipop update, we are releasing the Android 5.1 SDK (API Level 22) which supports the new platform and lets you get started with developing and testing.

What's new in Android 5.1?

For developers, Android 5.1 introduces a small set of new APIs. A key API addition is support for multiple SIM cards, which is important for many regions where Android One phones are being adopted. Consumers of Android One devices will have more flexibility to switch between carriers and manage their network activities in the way that works best for them. Therefore you, as a developer, can create new app experiences that take advantage of this new feature.

In addition to the new consumer features, Android 5.1 also enhances enterprise features to better support the launch of Android for Work.

Android 5.1 supports multiple SIM cards on compatible devices like Android One.

Updates for the Android SDK

To get you started with Android 5.1, we have updated the Android SDK tools to support the new platform and its new APIs. The SDK now includes Android 5.1 emulator system images that you can use to test your apps and develop using the latest capabilities and APIs. You can update your SDK through the Android SDK Manager in Android Studio.

For details on the new developer APIs, take a look at the API Overview.

Coming to Nexus devices soon

Over the next few weeks, we’ll be rolling out updates for Android 5.1 to the following Nexus devices: Nexus 4, Nexus 5, Nexus 6, Nexus 7 [2012], Nexus 7 [2012] (3G), Nexus 7 (2013), Nexus 7 [2013] (3G/LTE), Nexus 9, Nexus 9 (LTE), Nexus 10, and Nexus Player.

Next Steps

As with all Android releases, it’s a good idea to test your apps on the new platform as soon as possible. You can get started today using Android 5.1 system images with the emulator that’s included in the SDK, or you can download an Android 5.1 Nexus image and flash the system image to your Nexus device.

If you have not had a chance to update your app to material design, or explore how your app might work on Android Wear, Android TV, or even Android Auto, now is a good time to get started with the Android 5.1 SDK update.

Android 5.0 Lollipop SDK and Nexus Preview Images

Two more weeks!

By Jamal Eason, Product Manager, Android

At Google I/O last June, we gave you an early version of Android 5.0 with the L Developer Preview, running on Nexus 5, Nexus 7 and Android TV. Over the course of the L Developer Preview program, you’ve given us great feedback and we appreciate the engagement from you, our developer community. Thanks!

This week, we announced Android 5.0 Lollipop. Starting today, you can download the full release of the Android 5.0 SDK, along with updated developer images for Nexus 5, Nexus 7 (2013), ADT-1, and the Android emulator.

The first set of devices to run this new version of Android -- Nexus 6, Nexus 9, and Nexus Player -- will be available in early November. In the same timeframe, we'll also roll out the Android 5.0 update worldwide to Nexus 4, 5, 7 (2012 & 2013), and 10 devices, as well as to Google Play edition devices.

Therefore, now is the time to test your apps on the new platform. You have two more weeks to get ready!

What’s in Lollipop?

Android 5.0 Lollipop introduces a host of new APIs and features including:

There's much more, so check out the Android 5.0 platform highlights for a complete overview.

What’s in the Android 5.0 SDK?

The Android 5.0 SDK includes updated tools and new developer system images for testing. You can develop against the latest Android platform using API level 21 and take advantage of the updated support library to implement Material Design as well as the leanback user interface for TV apps.

You can download these components through the Android SDK Manager and develop your app in Android Studio:

  • Android 5.0 SDK Platform & Tools
  • Android 5.0 Emulator System Image - 32-bit & 64-bit (x86)
  • Android 5.0 Emulator System Image for Android TV (32-bit)
  • Android v7 appcompat Support Library for Material Design theme backwards capability
  • Android v17 leanback library for Android TV app support

For developers using the Android NDK for native C/C++ Android apps we have:

For developers on Android TV devices we have:

  • Android 5.0 system image over the air (OTA) update for ADT-1 Developer Kit. OTA updates will appear over the next few days.

Similar to our previous release of the preview, we are also providing updated system image downloads for Nexus 5 & Nexus 7 (2013) devices to help with your testing as well. These images support the Android 5.0 SDK, but only have the minimal apps pre-installed in order to enable developer testing:

  • Nexus 5 (GSM/LTE) “hammerhead” Device System Image
  • Nexus 7 (2013) - (Wifi) “razor” Device System Image

For the developer preview versions, there will not be an over the air (OTA) update. You will need to wipe and reflash your developer device to use the latest developer preview versions. If you want to receive the official consumer OTA update in November and any other official updates, you will have to have a factory image on your Nexus device.

Validate your apps with the Android 5.0 SDK

With the consumer availability of Android 5.0 and the Nexus 6, Nexus 9, and Nexus Player right around the corner, here are a few things you should do to prepare:

  • Get the emulator system images through the SDK Manager or download the Nexus device system images.
  • Recompile your apps against Android 5.0 SDK, especially if you used any preview APIs. Note: APIs have changed between the preview SDK and the final SDK.
  • Validate that your current Android apps run on the new API 21 level with ART enabled. And if you use the NDK for your C/C++ Android apps, validate against the 64-bit emulator. ART is enabled by default on API 21 & new Android devices with Android 5.0.

Once you validate your current app, explore the new APIs and features for Android 5.0.

Migrate Your Existing App to Material Design

Android 5.0 Lollipop introduces Material Design, which enables your apps to adopt a bold, colorful, and flexible design, while remaining true to a small set of key principles that guide user interaction across multiple screens and devices.

After making sure your current apps work with Android 5.0, now is the time to enable the Material theme in your app with the AppCompat support library. For quick tips & recommendations for making your app shine with Material Design, check out our Material Design guidelines and tablet optimization tips. For those of you new to Material Design, check out our Getting Started guide.

Get your apps ready for Google Play!

Starting today, you can publish your apps that are targeting Android 5.0 Lollipop to Google Play. In your app manifest, update android:targetSdkVersion to "21", test your app, and upload it to the Google Play Developer Console.

Starting November 3rd, Nexus 9 will be the first device available to consumers that will run Android 5.0. Therefore, it is a great time to publish on Google Play, once you've updated and tested your app. Even if your apps target earlier versions of Android, take a few moments to test them on the Android 5.0 system images, and publish any updates needed in advance of the Android 5.0 rollout.

Stay tuned for more details on the Nexus 6 and Nexus 9 devices, and how to make sure your apps look their best on them.

Next up, Android TV!

We also announced the first consumer Android TV device, Nexus Player. It’s a streaming media player for movies, music and videos, and also a first-of-its-kind Android gaming device. Users can play games on their HDTVs with a gamepad, then keep playing on their phones while they’re on the road. The device is also Google Cast-enabled, so users can cast your app from their phones or tablets to their TV.

If you’re developing for Android TV, watch for more information on November 3rd about how to distribute your apps to Android TV users through the Google Play Developer Console. You can start getting your app ready by making sure it meets all of the TV Quality Guidelines.

Get started with Android 5.0 Lollipop platform

If you haven’t had a chance to take a look at this new version of Android yet, download the SDK and get started today. You can learn more about what’s new in the Android 5.0 platform highlights and get all the details on new APIs and changed behaviors in the API Overview. You can also check out the latest DevBytes videos to learn more about Android 5.0 features.

Enjoy this new release of Android!

New in Android: L Developer Preview and Google Play Services 5.0

By Jamal Eason, Product Manager, Android

Earlier today, at Google I/O, we showed a number of projects we’ve been working on to the thousands of developers in the audience and the millions more tuning in on the livestream. These projects extend Android to the TV (Android TV), to the car (Android Auto) and to wearables (Android Wear), among others.

At Google, our focus is providing a seamless experience for users across all of the screens in their lives. An important component to that is making sure that you as developers have all of the tools necessary to easily deploy your apps across to those screens. Increasingly, Android is becoming the fabric that weaves these experiences together, which is why you’ll be excited about a number of things we unveiled today.

Android L Developer Preview

For the first time since we launched Android, we’re giving you early access to a development version of an upcoming release. The L Developer Preview, available starting tomorrow, lets you explore many of the new features and capabilities of the next version of Android, and offers everything you need to get started developing and testing on the new platform. This is important because the platform is evolving in a significant way — not only for mobile but also moving beyond phones and tablets. Here are a few of the highlights for developers:

  • Material design for the multiscreen world — We’ve been working on a new design language at Google that takes a comprehensive approach to visual, motion, and interaction design across a number of platforms and form factors. Material design is a new aesthetic for designing apps in today’s multi-device world. The L Developer Preview brings material design to Android, with a full set of tools for your apps. The system is incredibly flexible, allowing your app to express its individual character and brand with bold colors and a variety of responsive UI patterns and themeable elements.
  • Enhanced notifications — New lockscreen notifications let you surface content, updates, and actions to users at a glance, without unlocking. Visibility controls let you manage the types of information shown on the lockscreen. Heads-up notifications display content and actions in a small floating window that’s managed by the system, no matter which app is in the foreground. Notifications are material themed and you can express your brand through accent colors and more.
  • Document-centric Recents — Now you can organize your app by tasks and present these concurrently as individual “documents” in the Recents screen. Users can flip through Recents to find the specific task they want and then jump deep into your app with a single tap.
  • Project Volta — New tools and APIs help your app run efficiently and conserve power. Battery Historian is a new tool that lets you visualize power events over time and understand how your app is using battery. A job scheduler API lets you set the conditions under which your background tasks and other jobs should run, such as when the device is idle or connected to an unmetered to a charger, to minimize battery impact.
  • BLE Peripheral Mode — Android devices can now function in Bluetooth Low Energy (BLE) peripheral mode. Apps can use this capability to broadcast their presence to nearby devices — for example, you can now build apps that let a device to function as a pedometer or health monitor and transmit data to another BLE device.
  • Multi-networking — Apps can work with the system to dynamically scan for available networks with specific capabilities and then automatically connect. This is useful when you want to manage handoffs or connect to a specialized network, such as a carrier-billing network.
  • Advanced camera capabilities — A new camera API gives you new capabilities for image capture and processing. On supported devices, your app can capture uncompressed YUV capture at full 8 megapixel resolution at 30 FPS. The API also lets you capture raw sensor data and control parameters such as exposure time, ISO sensitivity, and frame duration, on a per-frame basis.
  • New features for game developers — Support for OpenGL ES 3.1, gives you capabilities such as compute shaders, stencil textures, and texture gather for your games. Android Extension Pack (AEP) is a new set of extensions to OpenGL ES that bring desktop-class graphics to Android. Games will be able to take advantage of tessellation and geometry shaders, and use ASTC texture compression across multiple GPU techonolgies.
  • Android Runtime (ART) — The L Developer Preview introduces the Android Runtime (ART) as the system default. ART offers ahead-of-time (AOT) compilation, more efficient garbage collection, and improved development and debugging features. In many cases it improves performance of the device with no action required by the developer.
  • 64-bit support — The L Developer Preview adds support for 64-bit ABIs, for additional address space and improved performance with certain compute workloads. Apps written in the Java language can run immediately on 64-bit architectures with no modifications required. To support apps using native code, we’re also releasing an updated NDK that includes 64-bit support.

Watch for more details coming out tomorrow (26 June) on what’s in the L Developer Preview and how to get it.

Google Play Services 5.0

Along with the L Developer Preview, we also announced a new version of Google Play services that brings new capabilities and the latest optimizations to devices across the Android ecosystem. Google Play services ensures that you can build on the latest features from Google for your users, with the confidence that those services will work properly everywhere. The latest version has begun rolling out and here are some of the highlights:

  • Services for Android wearables — Your apps can more easily communicate and sync with code running on Android wearables through an automatically synchronized, persistent data store and a reliable messaging interface.
  • Play Games services — Build a great gaming experience with Quests, which allow event-based challenges for players to complete for rewards, Saved Games (a snapshot API allow synchronization of game data along with a cover-image and description), and Game Profile (providing experience points for players).
  • App Indexing API — Surface deep content in your native mobile applications on Google search and drive additional user engagement.
  • Google Cast — Use media tracks to enable closed-caption support for Chromecast.
  • Drive — Sort query results, create offline folders, and select any mime type in the file picker by default.
  • Wallet — Build a "Save to Wallet" button for offers directly into your app; use geo-fenced in-store notifications to prompt the user to show and scan digital cards. Split tender allows payment to be split between Wallet Balance and a credit/debit card in Google Wallet.
  • Analytics — Get insights into the full user journey and understand how different user acquisition campaigns are performing with Enhanced Ecommerce, letting you measure product impressions, product clicks, and more.
  • Mobile Ads — Use improved in-app purchase ads and integrations for the Play store in-app purchase API client.
  • Dynamic Security Provider — Offers an alternative to the platform's secure networking APIs that can be updated more frequently, for faster delivery of security patches.

We expect the rollout of Google Play services 5.0 to take several days, after which time you’ll be able to get started developing with these new APIs.

Join us at the Google I/O sessions

If you’d like to learn more, join us for sessions on Android development, material design, game development, and more. You’ll find the full session list on the Google I/O 2014 site, and you can filter the schedule to find livestreamed sessions of interest.

Explore the conference with the Google I/O 2014 Android app:

Get it on Google Play