Tag Archives: Tablets

Enhanced screen sharing capabilities in Android 14 (and Google Meet) improve meeting productivity

Posted by Francesco Romano – Developer Relations Engineer on Android

App screen sharing improves privacy and productivity

Android 14 QPR2 brings exciting advancements in user privacy and streamlined multitasking with app screen sharing. No longer do users have to broadcast their entire screen while screen sharing or casting, ensuring they share exactly what they want to share.

Leverage the new MediaProjection APIs to customize the screen sharing experience and deliver even greater utility to your users.

What is app screen sharing?

Prior to Android 14, users could only share or record their entire screen on Android devices, which could expose private information in other apps or notifications.

App screen sharing is a new platform feature that lets users restrict sharing and recording to a single app window, mitigating the risk of oversharing private messages or notifications. With app screen sharing, the status bar, navigation bar, notifications, and other system UI elements are excluded from the shared display. Only the content of the selected app is shared.

This not only enhances security for screen sharing, but also enables new use cases on large screens. Users can improve multitasking productivity – such as screen sharing while attending a meeting – by taking advantage of extra screen space on these larger devices.

How does it work?

There are three different entry points for users to start app screen sharing:

Start casting from Quick Settings
Start screen recording from Quick Settings
Launch from an app with screen sharing or recording capabilities via the MediaProjection API

Let’s consider an example where a host user wants to share a single app to the participants of a video call.

The host user starts screen sharing as usual, but now in Android 14 they are presented with an updated dialog that allows them to choose whether to share a single app instead of their entire screen.

The host user decides to share a single app, and they select the app from the App Selector.

During screen sharing, the video call participants can see only the content from the selected app.

The host user can end the screen capture in a few ways: from the app where sharing started, in the notification shade, by closing the app being shared, or by ending the video call.

visual journey of host sharing a single app to the participants in a video call across four panels

How to support app screen sharing?

Apps that use the MediaProjection APIs are capable of starting app screen sharing without any code changes. However, it’s important to test your app to ensure that the screen sharing experience works as intended, since the user flow changes with this new behavior. Previously, the user would stay in the host app after the permission dialog. With app screen sharing the user is not returned to the host app, but the target app to be shared is launched instead. If the target app was already running in foreground (e.g. in multi window mode), then it simply becomes the top focused app.

Android 14 also introduces two callback methods to empower you to customize the sharing experience:

MediaProjection.Callback#onCapturedContentResize(width, height) is invoked immediately after capture begins or when the size of the captured region changes. The method arguments provide the accurate sizing for the streamed capture.

Note: The given width and height correspond to the same width and height that would be returned from android.view.WindowMetrics#getBounds() of the captured region.

If the recorded content has a different aspect ratio from either the VirtualDisplay or output Surface, the captured stream has black bars around the recorded content. The application can avoid the black bars around the recorded content by updating the size of both the VirtualDisplay and output Surface:

override fun onCapturedContentResize(width: Int, height: Int): String {
    // VirtualDisplay instance from MediaProjection#createVirtualDisplay().
    virtualDisplay.resize(width, height, dpi)

    // Create a new Surface with the updated size.
    val textureName: Int // the OpenGL texture object name
    val surfaceTexture = SurfaceTexture(textureName)
    surfaceTexture.setDefaultBufferSize(width, height)
    val surface = Surface(surfaceTexture)

    // Ensure the VirtualDisplay has the updated Surface to send the capture to.
    virtualDisplay.setSurface(surface)
}

The other API is MediaProjection.Callback#onCapturedContentVisibilityChanged(isVisible), which is invoked after capture begins or when the visibility of the captured region changes. The method argument indicates the current visibility of the captured region.

The callback is triggered when:

The captured region becomes invisible (isVisible==False).This may happen when the projected app is not topmost anymore, like when another app entirely covers it, or the user navigates away from the captured app.
The captured region becomes visible again (isVisible==True).This may happen if the user moves the covering app to show at least some portion of the captured app (for example, the user has multiple apps visible in multi-window mode).

Applications can take advantage of this callback by showing or hiding the captured content from the output Surface based on whether the captured region is currently visible to the user. You should pause or resume the sharing accordingly in order to conserve resources.

How Google Meet is improving meeting productivity

“App screen sharing enables users to share specific information in a Meet call without oversharing private information on the screen like messages and notifications. Users can choose specific apps to share, or they can share the whole screen as before. Additionally, users can leverage split-screen mode on large screen devices to share content while still seeing the faces of friends, families, coworkers, and other meeting participants.” - Product Manager at Google Meet

Let’s see app screen sharing in action during a video call, in this coming-soon version of Google Meet!

moving image of app screen sharing in action during a video call on Google Meet

Window on the world

App screen sharing opens doors (and windows) for more focused and secure app experiences within the Android ecosystem.

This new feature enhances several use cases:

Collaboration apps can facilitate focused discussion on specific design elements, documents, or spreadsheets without including distracting background details.
Tech support agents can remotely view the user's problem app without seeing potentially sensitive content in other areas.
Video conferencing tools can share a presentation window selectively rather than the entire screen.
Educational apps can demonstrate functionality without compromising student privacy, and students can share projects without fear of showing sensitive information.

By thoughtfully implementing app screen sharing, you can establish your app as a champion of user privacy and convenience.

Source: Android Developers Blog

Detecting device type – How to know if a device is foldable or a tablet

Posted by Alex Vanyo, Developer Relations Engineer

With the increase in Android apps being used on large screen form factors like foldables and tablets, more and more apps are building fully adaptive UIs. See Support different screen sizes for best practices for updating your app for best practices for updating your app. The bottom line is that Layout and app behavior should be based on device configuration and available features, and not the physical type of the device.

At the same time, we get this question a lot: “Is there an easy way to tell if a device is a foldable, tablet, or something else?”

It might seem that using the physical type of device provides all the information developers need to create great experiences. However, we can make more adaptive apps with a better user experience by adding more context. For example:

Do you want “flip”-style phones to count as foldables?

Do you want to determine if a device is a tablet, or just if cellular functionality is available?

What would rollables count as? What about ChromeOS devices, or other desktop devices that can run Android apps?

The most common reason app developers want to know the type of the device is so they can determine what kind of layout to show. But with the increase of split-screen and multi-window usage on large screens, making layout decisions based on device type leads to incorrect layout decisions in certain scenarios on large screen devices.

As we’ve been updating our own apps to better support more devices, we have seen a few important use cases to highlight further. We will cover four main scenarios:

Layouts - Display the most appropriate UI for different devices and folding postures

Hardware features - Implement support for a variety of hardware features

Displaying the name of the physical device type to the user - Personalize end-user facing information for the type of device.

Metrics tracking for device type - Understand how users are using your app on different types of devices

Layouts

Goal

Display the most appropriate UI for different devices, display modes, and folding postures.

Recommended Solution

Use window size classes to guide layout decisions based on your current windowing state using opinionated breakpoints that are derived from common device types. Don't restrict orientation or resizability; you prevent users from using your application in their desired manner.

Observe folding features with Jetpack WindowManager, which provides the set of folding features that intersect your app's current window. Note that even if your activity isn’t receiving any folding features, it could still be running on a device capable of folding – on the outer screen, on the inner screen in a small window, or on an external display.

Why

Historically, multiple distinct layouts were created for different screen sizes, often with a “tablet” layout and a “phone” layout. These two layouts then existed together, and both had to be kept up to date as the app changed. Referring to these layouts as “tablet” and “phone” layouts was useful when the device manufacturers by and large limited themselves to making devices that fit cleanly into these two categories. Users today have a lot more choice as manufacturers are creating devices that are more physically varied, and usable in different ways.

A single device may sometimes have enough room to display a "tablet"-sized layout, while other times (for example, a folded foldable or split screen) the device may only have enough room to display a “phone” layout. There are even cases where a smaller layout is desired such as foldable flip phone cover displays.

This could be due to a foldable that has a smaller outer screen and a larger inner screen, or whenever the user enters multi-window mode and adjusts freeform windowing environments. Critically, the type of app layout should not be decided by the physical type of the device; it should be decided by the current size of the app’s window, which may or may not be full screen on the current device display.

On large screen devices running Android 12L and higher, apps that restrict the orientation or resizability can be placed into compatibility mode as the device is rotated or folded or the app enters multi-window mode. Compatibility mode letterboxes the app, preserving the app's specified restrictions, but missing the opportunity to display more, useful content to the user.

Hardware features

Goal

Implement support for a variety of hardware features (for example, if the device has a SIM).

Recommend Solution

Make dynamic, runtime decisions based on whether a feature is available, instead of assuming that a feature is or is not available for a certain kind of device.

If your app has a feature that is absolutely required, Google Play respects the required uses-feature declarations in your manifest. However, be mindful that any required features reduce the set of devices that your app can be installed on, and adding new required features prevents updates to previously supported devices.

Why

There are many hardware features that are present on some Android devices, but not present on others. As devices continue to evolve, we’ve seen multiple cases where user-facing features are not supported, because developers assume that a physical type of device doesn’t support a particular hardware feature.

For example, we’ve seen cases where biometric authentication isn’t offered as a login option on tablets that support biometric authentication, even when the same app supports biometric authentication on phones. Biometric authentication should be an option for the user if the device supports it, not based on the type of device.

Another example is assuming cellular connectivity is limited to standard-size phones. Foldable devices might have “tablet”-sized screens, but foldables still have a cellular connection and a phone number. If a device has the capability, the user should be able to choose to use the device accordingly.

Some hardware features are also dynamically available. Peripherals might be attached and detached by the user, and apps should gracefully handle gaining and losing access to these features. Hardware features like the camera and microphone can only be used by one app at a time, so multi-tasking between different apps may also result in losing access to hardware features.

Displaying physical device type to the user

Goal

Personalize user-facing information by type of device (for example, "Run on your tablet")

Recommendation

Referring in the UI to the user’s device as simply a “device” covers all form factors and is the simplest to implement. However, differentiating between the multiple devices a user may have provides a more polished experience and enables you to display the type of the device to the user using heuristics relevant to your particular use case.

For example, Google Play currently uses the following heuristics for determining the device name to display to the user when installing an app on a particular device. The logic is specific to this particular use case, and may change as devices and form factors evolve.

Chart showing Google Play Device Display Names as of June 2023. If the device has all built-in display(s) screen width less than 600dp with or without a hinge, it's considered a phone. When the device has built-in display with screen width greater than or equal to 600dp, if it has a hinge it is considered a foldable, and without a hinge it is considered a tablet. — *Google Play Device Display Name logic as of June 2023*

Why

If you are displaying the type of the device to the user, and want to differentiate between the physical type of the device for personalizing the experience, such as to say “download on your foldable” or to show more specific device imagery, you can use the available physical features as heuristics for which type of device the user is using. However, these are only heuristics and could change as the accepted terms for referring to the devices themselves change. As discussed above, a foldable device may or may not support other hardware features, or have a large screen.

“Foldable” heuristic:

If a device has a hinge sensor (which can be determined by PackageManager.hasSystemFeature(PackageManager.FEATURE_SENSOR_HINGE_ANGLE)), then the device supports folding in some manner. Note: While this covers most foldables moving forward, it may not cover some older foldables that don’t expose a hinge sensor. Additionally, the screen the app is being displayed on may or may not fold, the device might have an additional non-folding screen as well, or the screen may not currently be folded, even if it could fold. Devices like the Samsung Flip have a smallest width of less than 600dp, The inner screen of large-screen foldables have a smallest width of 600dp or more.

“Phone” heuristic:

99.96% of phones have a built-in screen with a width smaller than 600dp when in portrait, but that same screen size could be the result of a freeform/split-screen window on a tablet or desktop device.

“Desktop” heuristic:

Desktop devices, like ChromeOS devices, running Android apps, may expose specific features or environment information that apps can use. For instance, ChromeOS has the system feature "org.chromium.arc" or “org.chromium.arc.device_management” to enable developers to determine whether their app is running on ChromeOS. But apps running on tablets – and phones, if the user so chooses – may also use desktop-class keyboards and mice for enhanced productivity.

Metrics tracking for device type

Goal

Understand how users are using your app on different types of devices.

Recommendation

Use the heuristics and features discussed above as inputs to your analytics, while keeping in mind that physical device type doesn’t give the complete story for how users are using your app on that device.

Why

Even if the user is using a device that can physically fold, they may be using the app in multiple configurations. Users might use an app more or less on the inner screen compared to the outer screen, and they might multi-task with other apps on the inner screen. For devices that support external displays, the app might not be running on either of a foldable's built-in physical displays.

Other information that might also be relevant:

Are there external peripherals being used to interact with the app, like keyboards, mice, trackpads, or styluses?

Does the device have a built-in touchscreen?

Is the app being used in a free-form windowing environment?

Conclusion

Don't make assumptions about what a particular physical device implies for your app. “Is the device foldable?” is a good starting point, but it shouldn’t be the only question you ask. Additional pieces of information will give a more precise and more relevant answer to your use case at hand, and each use case has different considerations that you should make to build versatile, adaptive apps.

Source: Android Developers Blog

Android developers: a big thank you for a great 2022!

Posted by Maru Ahues Bouza, Director, Android Developer Relations

This past year was a special one for the Android community, from the release of Android 13, a big investment in tablets and large screens, the latest in wearable technology to all of the investments in Modern Android Development! It was terrific to see many of you for the first time again in-person at Android Dev Summit and other events around the world.From the experiences you build for users to feedback you provide us to make your tools better, we wanted to say a very special holiday thank you!

We put together a highlights recap, and a commemorative poster celebrating 2022 - download it to bring some holiday cheer to your workspace, wherever you may be this season.

Have a festive holiday season and we look forward to continuing our work with you in the new year.

Source: Android Developers Blog

13 Things to know for Android developers at Google I/O!

Posted by Maru Ahues Bouza, Director of Android Developer Relations

Android I/O updates: Jetpack, Wear OS, etc

There aren’t many platforms where you can build something and instantly reach billions of people around the world, not only on their phones—but their TVs, cars, tablets, watches, and more. Today, at Google I/O, we covered a number of ways Android helps you make the most of this opportunity, and how Modern Android Development brings as much commonality as possible, to make it faster and easier for you to create experiences that tailor to all the different screens we use in our daily lives.

We’ve rounded up the top 13 things to know for Android developers—from Jetpack Compose to tablets to Wear OS and of course… Android 13! And stick around for Day 2 of Google I/O, when Android’s full track of 26 technical talks and 4 workshops drop. We’re also bringing back the Android fireside Q&A in another episode of #TheAndroidShow; tweet us your questions now using #AskAndroid, and we’ve assembled a team of experts to answer live on-air, May 12 at 12:30PM PT.

MODERN ANDROID DEVELOPMENT

#1: Jetpack Compose Beta 1.2, with support for more advanced use cases

Android’s modern UI toolkit, Jetpack Compose, continues to bring the APIs you need to support more advanced use cases like downloadable fonts, LazyGrids, window insets, nested scrolling interop and more tooling support with features like LiveEdit, Recomposition Debugging and Animation Preview. Check out the blog post for more details.

#2: Android Studio: introducing Live Edit

Get more done faster with Android Studio Dolphin Beta and Electric Eel Canary! Android Studio Dolphin includes new features and improvements for Jetpack Compose and Wear OS development and an updated Logcat experience. Android Studio Electric Eel comes with integrations with the new Google Play SDK Index and Firebase Crashlytics. It also offers a new resizable emulator to test your app on large screens and the new Live Edit feature to immediately deploy code changes made within composable functions. Watch the What’s new in Android Development Tools session and read the Android Studio I/O blog post here.

#3: Baseline Profiles - speed up your app load time!

The speed of your app right after installation can make a big difference on user retention. To improve that experience, we created Baseline Profiles. Baseline Profiles allow apps and libraries to provide the Android runtime with metadata about code path usage, which it uses to prioritize ahead-of-time compilation. We've seen up to 30% faster app startup times thanks to adding baseline profiles alone, no other code changes required! We’re already using baseline profiles within Jetpack: we’ve added baselines to popular libraries like Fragments and Compose – to help provide a better end-user experience. Watch the What’s new in app performance talk, and read the Jetpack blog post here.

BETTER TOGETHER

#4: Going big on Android tablets

Google is all in on tablets. Since last I/O we launched Android 12L, a release focused on large screen optimizations, and Android 13 includes all those improvements and more. We also announced the Pixel tablet, coming next year. With amazing new hardware, an updated operating system & Google apps, improved guidelines and libraries, and exciting changes to the Play store, there has never been a better time to review your apps and get them ready for large screens and Android 13. That’s why at this year’s I/O we have four talks and a workshop to take you from design to implementation for large screens.

#5: Wear OS: Compose + more!

With the latest updates to Wear OS, you can rethink what is possible when developing for wearables. Jetpack Compose for Wear OS is now in beta, so you can create beautiful Wear OS apps with fewer lines of code. Health Services is also now in beta, bringing a ton of innovation to the health and fitness developer community. And last, but certainly not least, we announced the launch of The Google Pixel Watch - coming this Fall - which brings together the best of Fitbit and Wear OS. You can learn more about all the most exciting updates for wearables by watching the Wear OS technical session and reading our Jetpack Compose for Wear OS announcement.

#6: Introducing Health Connect

Health Connect is a new platform built in close collaboration between Google and Samsung, that simplifies connectivity between apps making it easier to reach more users with less work, so you can securely access and share user health and fitness data across apps and devices. Today, we’re opening up access to Health Connect through Jetpack Health—read our announcement or watch the I/O session to find out more!

#7: Android for Cars & Android TV OS

Android for Cars and Android TV OS continue to grow in the US and abroad. As more users drive connected or tune-in, we’re introducing new features to make it even easier to develop apps for cars and TV this year. Catch the “What’s new with Android for Cars” and “What's new with Google TV and Android TV” sessions on Day 2 (May 12th) at 9:00 AM PT to learn more.

#8: Add Voice Across Devices

We’re making it easier for users to access your apps via voice across devices with Google Assistant, by expanding developer access to Shortcuts API for Android for Cars, with support for Wear OS apps coming later this year. We’re also making it easier to build those experiences with Smarter Custom Intents, enabling Assistant to better detect broader instances of user queries through ML, without any NLU training heavy lift. Additionally, we’re introducing improvements that drive discovery to your apps via voice on Mobile, first through Brandless Queries, that drive app usage even when the user hasn’t explicitly said your app’s name, and App Install Suggestions that appear if your isn’t installed yet–these are automatically enabled for existing App Actions today.

AND THE LATEST FROM ANDROID, PLAY, AND MORE:

#9: What’s new in Play!

Get the latest updates from Google Play, including new ways Play can help you grow your business. Highlights include the ability to deep-link and create up to 50 custom listings; our LiveOps beta, which will allow more developers to submit content to be considered for featuring on the Play Store; and even more flexibility in selling subscriptions. Learn about these updates and more in our blog post.

#10: Google Play SDK Index

Evaluate if an SDK is right for your app with the new Google Play SDK index. This new public portal lists over 100 of the most widely used commercial SDKs and information like which app permissions the SDK requests, statistics on the apps that use them, and which version of the SDK is most popular. Learn more on our blog post and watch “What’s new in Google Play” and “What’s new in Android development tools” sessions.

#11: Privacy Sandbox on Android

Privacy Sandbox on Android provides a path for new advertising solutions to improve user privacy without putting access to free content and services at risk. We recently released the first Privacy Sandbox on Android Developer Preview so you can get an early look at the SDK Runtime and Topics API. You can conduct preliminary testing of these new technologies, evaluate how you might adopt them for your solutions, and share feedback with us.

#12: The new Google Wallet API

The new Google Wallet gives users fast and secure access to everyday essentials across Android and Wear OS. We’re enhancing the Google Wallet API, previously called Google Pay Passes API, to support generic passes, grouping and mixing passes together, for example grouping an event ticket with a voucher, and launching a new Android SDK which allows you to save passes directly from your app without a backend integration. To learn more, read the full blog post, watch the session, or read the docs at developers.google.com/wallet.

#13: And of course, Android 13!

The second Beta of Android 13 is available today! Get your apps ready for the latest features for privacy and security, like the new notification permission, the privacy-protecting photo picker, and improved permissions for pairing with nearby devices and accessing media files. Enhance your app with features like app-specific language support and themed app icons. Build with modern standards like HDR video and Bluetooth LE Audio. You can get started by enrolling your Pixel device here, or try Android 13 Beta on select phones, tablets, and foldables from our partners - visit developer.android.com/13 to learn more.

That’s just a snapshot of some of the highlights for Android developers at this year’s Google I/O. Be sure to watch the What’s New in Android talk to get the landscape on the full Android technical track at Google I/O, which includes 26 talks and 4 workshops. Enjoy!

Source: Android Developers Blog

Android @ Google I/O: Recapping building across devices

Posted by The Android Team

At Google I/O this year, we talked about how your app can take advantage of Android's different screens, both large and small. But if you missed the show, here are the top things you should know:

Tablets, Foldables, and Large Screens

It's more important than ever to design your app to work well on large screens — including tablets, foldables, and Chrome OS laptops. There are already over 250 million large screen Android devices in use today. Meanwhile, new foldable devices are making it easier for users to multitask, and opening up new experiences like tabletop mode for hands-free activities. See this example of Disney+ using tabletop mode on the Samsung Galaxy Z Fold2.

Fortunately, it's also easier than ever to design apps which seamlessly scale to adapt to any device size — including dynamically resizing on Chrome OS and foldable devices, taking advantage of Jetpack Compose or ConstraintLayout to build responsive layouts. We also studied how people interact with large screens, like where their fingers are placed, and we’re giving you APIs and Tools to make that experience easier:

SlidingPaneLayout 1.2.0 helps your content resize automatically to more space
Vertical navigation rails provide a more ergonomic experience on large screens
Constraint Layout 2.1 and MotionLayout help updating fold and transition states
Max widths on components avoid those terrible stretch UIs on larger activities
Jetpack WindowManager makes it easy to take advantage of new hardware features, like hinges and folds

We’ve also made updates to the Android platform, Chrome OS, and Jetpack WindowManager, so apps just work better by default. For example, many UI elements now have default Max Width values to make sure they look better on large screens, while changes to the Display API ensure that existing apps continue to render correctly on foldables even if they aren't using WindowManager to query window metrics.

Learn more about how we are helping you build for large screens with these I/O sessions:

For even more details, check out the what's new in foldables, tablets, and large screens article, or read the case study on how Google Duo sees increased engagement and improved ratings.

Wear OS

We announced our biggest update yet to the Wear platform, with new features, APIs and tools to help developers create beautiful, high quality wearable experiences.

There are new Jetpack APIs to help you streamline your development. The Tiles library gives users fast, predictable access to the information and actions they rely on most. Another notable addition is the Ongoing Activities API, which enables you to let your users return to your app after they’ve navigated away (to start some other task such as music playback). Both of these libraries are currently in alpha.

We also released a new set of APIs for health and fitness that act as an intermediary to the sensors and related algorithms on the device to provide apps with high-quality data related to activity, exercise, and health. The alpha of the Health Services platform is available to use today.

Download Android Studio Arctic Fox Beta to try out a developer preview of the new Wear system image and start preparing your apps for the new platform. Check out the I/O sessions below to learn more about these announcements:

You can also read more details on the latest changes to Wear, as well as learn about how Spotify is building on Wear.

Android TV

Android TV OS now has over 80 million monthly active devices, with 80% growth in the US and is at the heart of the Google TV experience launched last fall. Meanwhile, Google TV itself can be found on streaming devices like the Chromecast with Google TV, smart TVs from Sony, and as an app on Android devices — including tablets.

This year at I/O, we announced several new tools and features to make developing for Android TV OS easier:

Cast Connect with Stream Transfer allows moving existing audio and video streams between cast devices, while Stream Expansion allows playing audio on multiple devices simultaneously.
We are now making our first Google TV Emulator available alongside the Android TV emulator, both running on Android 11.
Firebase Test Lab is adding Android TV support, letting you test your app in the cloud across hundreds or thousands of virtual devices. Physical Devices will be coming soon.
We are making the Android 12 Beta 1 available for TV on ADT-3 today.

These releases make it easier to build and test applications across a range of device configurations, while bringing the latest Android 12, Googler Assistant, and Cast features to the TV. To learn more, watch the What's new in Android TV and Google TV session from I/O.

Android for Cars

Android Auto allows applications to connect with the infotainment displays built into many modern vehicles. To make this even easier we recently made the Android for Cars App Library available as part of Jetpack. This library allows navigation, EV charging, and parking apps to integrate directly with compatible cars.

We plan to expand to more app categories in the future, so if you’re expressing interest in bringing your app to Android Auto please fill out this interest form. You can also get started with the Android for Cars App Library today, by visiting g.co/androidforcars. Watch the What’s new with Android for Cars session from I/O for even more detail, or the accompanying What's new with Android for Cars blog post.

Source: Android Developers Blog

What’s new for Android developers at Google I/O

Cross-posted on the Android Developers blog by Karen Ng, Director, Product Management & Jacob Lehrbaum, Director of Developer Relations, Android & Play

As Android developers, we are all driven by building experiences that delight people around the world. And with people depending on your apps more than ever, expectations are higher and your jobs as developers aren’t getting easier. Today, at Google I/O, we covered a few ways that we’re trying to help out, whether it be through Android 12 - one of the biggest design changes ever, Jetpack, Jetpack Compose, Android Studio, and Kotlin to help you build beautiful high quality apps. We’re also helping when it comes to extending your apps wherever your users go, like through wearables and larger-screened devices. You can watch the full Developer Keynote, but here are a few highlights:

Android 12: one of the biggest design updates ever.

The first Beta of Android 12 just started rolling out, and it’s packed with lots of cool stuff. From new user safety features like permissions for bluetooth and approximate location, enhancements to performance like expedited jobs and start up animations, to delightful experiences with more interactive widgets and stretch overscrolling, this release is one of the biggest design updates to Android ever. You can read more about what’s in Android 12 Beta 1 here, so you can start preparing your apps for the consumer release coming out later this year. Download the Beta and try it with your apps today!

Jetpack Compose: get ready for 1.0 in July!

For the last few years, we’ve been hard at work modernizing the Android development experience, listening to your feedback to keep the openness–a hallmark of Android, but becoming more opinionated about the right way to do things. You can see this throughout, from Android Studio, a performant IDE that can keep up with you, to Kotlin, a programming language that enables you to do more with less code, to Jetpack libraries that solve the hardest problems on mobile with backward compatibility.

The next step in this offering is Jetpack Compose - our modern UI toolkit to easily build beautiful apps for all Android devices. We announced Compose here at Google I/O two years ago and since then have been building it in the open, listening to your feedback to make sure we got it right. With the Compose Beta earlier this year, developers around the world have created some truly beautiful, innovative experiences in half the time, and the response to the #AndroidDevChallenge blew our socks off!

With the forthcoming update of Material You (which you can read more about here), we’ll be adding new Material components as well as further support for building for large screens, making it fast and easy to build a gorgeous UI. We’re pressure testing the final bits in Compose and will release 1.0 Stable in July—so get ready!

Android Studio Arctic Fox: Design, Devices, & Developer Productivity!

Android Studio Arctic Fox (2020.3.1) Beta, the latest release of the official powerful Android IDE, is out today to help you build quality apps easier and faster. We have delivered and updated the suite of tools to empower three major themes: accelerate your UI design, extend your app to new devices, and boost your developer productivity. With this latest release you can create modern UIs with Compose tooling, see test results across multiple devices, and optimize debugging databases and background tasks with the App Inspector. We’re also making your apps more accessible with the Accessibility Scanner and more performant with Memory Profiler. And for faster build speeds, we have the Android Gradle plugin 7.0, new DSL, and variant APIs. You can learn more about the Android Studio updates here.

Kotlin: the most used language by professional Android devs

Kotlin is now the most used primary language by professional Android developers according to our recent surveys; in fact, over 1.2M apps in the Play Store use Kotlin, including 80% of the top 1000 apps. And here at Google, we love it too: 70+ Google apps like Drive, Home, Maps and Play use Kotlin. And with a brand-new native solution to annotation processing for Kotlin built from the ground up, Kotlin Symbol Processing is available today, a powerful and yet simple API for parsing Kotlin code directly, showing speeds up to 2x faster with libraries like Room.

Android Jetpack: write features, not boilerplate

With Android Jetpack, we built a suite of libraries to help reduce boilerplate code so you can focus on the code you care about. Over 84% of the top 10,000 apps are now using a Jetpack library. And today, we’re unpacking some new releases for Jetpack, including Jetpack Macrobenchmark (Alpha) to capture large interactions that affect your app startup and jank before your app is released, as well as a new Kotlin Coroutines API for persisting data more efficiently via Jetpack DataStore (Beta). You can read about all the updates in Android Jetpack here.

Now is the time: a big step for Wear

The best thing about modern Android development is that these tools have been purpose built to help make it easy for you to build for the next era of Android, which is all about enabling devices connected to your phone–TVs, cars, watches, tablets–to work better together.

Starting today, we take a huge step forward with wearables. First, we introduced a unified platform built jointly with Samsung, combining the best of Wear and Tizen. Second, we shared a new consumer experience with revamped Google apps. And third, a world-class health and fitness service from Fitbit is coming to the platform. As an Android developer, it means you’ll have more reach, and you’ll be able to use all of your existing skills, tools, and APIs that make your mobile apps great, to build for a single wearables platform used by people all over the world.

Whether it’s new Jetpack APIs for Wear tailored for small screens and designed to optimize battery life, to the Jetpack Tiles API, so you can create a custom Tile for all the devices in the Wear ecosystem, there are a number of new features to help you build on Wear. And with a new set of APIs for Health and Fitness, created in collaboration with Samsung, data collection from sensors and metrics computation is streamlined, consistent, and accurate–like heart rate to calories to daily distance–from one trusted source. All this comes together in new tooling, with the release of Android Studio Arctic Fox Beta, like easier pairing to test apps, and even a virtual heart rate sensor in the emulator. And when your app is ready, users will have a much easier time discovering the world of Wear apps on Google Play, with some big updates to discoverability. You can read more about all of the Wear updates here.

Tapping the momentum of larger screens, like tablets, Chrome OS and foldables

When it comes to larger screens -- tablets, foldables, and Chrome OS laptops-- there is huge momentum. People are increasingly relying on large screen devices to stay connected with family and friends, go to school, or work remotely. In fact, there are over 250 million active large screen Android devices. Last year, Chrome OS grew +92% year over year–5 times the rate of the PC market, making Chrome OS the fastest growing and the second-most popular desktop OS. To help you take advantage of this momentum, we’re giving you APIs and tools to make optimizing that experience easier: like having your content resize automatically to more space by using SlidingpaneLayout 1.2.0 and a new vertical navigation rail component, Max widths on components to avoid stretched UIs, as well as updates to the platform, Chrome OS, and Jetpack windowmanager, so apps work better by default. You can learn more here.

Google Duo's optimized experience for foldable devices

This is just a taste of some of the new ways we’re making it easier for you to build high quality Android apps. Later today, we’ll be releasing more than 20 technical sessions on Android and Play, covering a wide range of topics such as background tasks, privacy, and Machine Learning on Android, or the top 12 tips to get you ready for Android 12. If building for cars, TVs, and wearables is your thing, we got that covered, too. You can find all these sessions - and more - on the I/O website. Beyond the sessions and news, there’s a number of fun ways to virtually connect with Googlers and other developers at this year’s Google I/O. You can check out the Android dome in I/O Adventure, where you can see new blog posts, videos, codelabs, and more. Maybe even test out your Jetpack Compose skills or take a virtual tour of the cars inside our dome!

Source: Google Developers Blog

What’s new in foldables, tablets, and large screens

Posted by Oscar Wahltinez, Developer Relations Engineer, Google

Users are seeing more value in larger screens, and the benefits of doing more with a single device. Apps designed for large screen devices increase those benefits even further.

The ability to fold a screen offers better ergonomics for large devices. When folded, you can fit a tablet-sized screen in your pocket — unlocking utility that was previously unavailable on a portable device. Thinking about our app ecosystem, we’re excited because this is a hardware shift that is driving new expectations around what you can do from a handheld device. We see the demand for larger screens extending to tablets too, which have greatly increased in popularity, given the similar app experience.

Technological breakthroughs and our understanding of ergonomics have played a role in device form factors.

In this blog post, we'll explain what you should do to prepare your apps for large screens, and how recent updates have made developing your app easier. But first, let’s talk about what we're seeing with large screens — and why you should optimize your app.

Why large screens

There are many ways to use foldable devices, including a number of postures illustrated here.

Over the past year, we’ve seen device makers release exciting new foldable and tablet devices. Demand has increased as users are doing more than ever from these devices. Altogether, developers can reach more than 250 million active foldables, tablets, and Chromebooks by building for Android large screen devices today. Sales of tablet devices grew 16% in 2020 with analysts expecting more than 400 million Android tablets by 2023, and foldables are redefining what’s possible on premium devices. Android apps can also run on ChromeOS, which is now the second most popular desktop OS.

Large screen ready

Larger screens are changing how users interact with their device. These devices allow you to edit slide decks while looking at notes, look up restaurant recommendations while planning a night out, or watch a video while chatting with friends. Let’s talk about base-level support — features an app must support to be “large screen ready”. There are three main areas of focus when it comes to large screen readiness:

Designing for large screens
Multitasking
Input modes

They’re summarized below, but make sure to check out our large screen app quality guidelines for the full details.

Design for large screens

The first step is to ensure that your app is designed for large screens. To make this easier, we’ve defined specific window size breakpoints and device classes for you to optimize for. Add tablet layouts for displays where the shortest dimension is >600dp, and ensure your apps go edge-to-edge. Developers should also plan for their app to be used in both portrait and landscape modes, since larger screens are more likely to be used in landscape. We’ve got material adaptive components that we’ll be talking about to help developers make better use of the increased space.

Since foldable and large screen devices have a variable window size, adaptive layouts work better than splitting experiences based on screen size.

Multitasking

Going into split screen (or multi-window mode) and gestures like drag and drop are starting to become natural interactions that users expect to work seamlessly in their large screen devices. Your apps should handle multitasking seamlessly by being resizable. Handling folding and unfolding events and planning for your app to be in multi-window mode prevents your app from becoming letterboxed.

Drag and drop can be a natural interaction in large screen layouts, even within the same app.

By enabling multiple instance support, users can run multiple copies of your app side-by-side. The let’s users compare two products, reference notes while writing a document or maybe keeping your calendar in view as you are planning an event.

Input modes

Since many people use larger screens for productivity, tablets should support basic keyboard, mouse and stylus usage.

Users of Android apps on ChromeOS devices often have a keyboard; apps should ensure that standard keyboard navigation and shortcuts are available to provide improved accessibility.

Component updates

Several UI components across Jetpack and Material Design libraries have been updated to help you build a flexible user experience to scale your phone's UI to a larger screen.

SlidingPaneLayout

One of the most common adaptive layouts to optimize your app for large screens is implementing a list-detail UI. For example, a messaging app that lists messages on one side with the message detail on the other.

SlidingPaneLayout automatically adapts to configuration changes to provide a good user experience across different layout sizes.

UIs that would be one top of each other on a smaller screen can now easily lay out side-by-side. For this, you can use the updated version of the SlidingPaneLayout library — updated to support a two-pane style layout, SlidingPaneLayout uses the width of the two panes to determine how to lay out the UI. It does that by automatically determining if it can lay out side-by-side based on the content width and available space. For example, if the list pane is measured to have a minimum width of 200dp and the detail pane needs 400dp, then the SlidingPaneLayout automatically shows the two panes side by side if it has at least 600dp of width available.

SlidingPaneLayout is used in our sample application IOSched.

We have updated the library to recognize and adapt to folds and hinges . For example, if you are on a device with hinges that blocks part of the screen, it will automatically place your content on either side.

We have also introduced lock modes,which allow control over the swipe behavior when panes overlap (programmatically switching is also supported). For example, to prevent users from swiping to an empty pane you may want them to have to click on a list item to load information about that pane, but allow them to swipe back to the list. On a foldable device or tablet that has room to show both views side by side, the lock modes are ignored.

NavRail

A vertical Navigation Rail is functionally equivalent to Bottom navigation, and provides a more ergonomic navigation experience on larger screens. As you scale your UI, NavRail supports better reachability, since larger screens tend to be held by the side, whereas on the phone users are probably holding the device from the bottom.

NavRail automatically changes the location of the navigation menu depending on configuration changes.

For example, NavRail can help if vertical scrolling is key to your app. In those cases, a bottom navigation bar decreases the amount of content that’s visible, especially when tablet devices are being used in landscape orientation.

Other Components

We've also made updates across multiple other components. One of the biggest pitfalls when apps move to a larger screen is when UIs are stretched edge-to-edge across the whole screen. To help prevent this, we’ve added default Max Width values to certain Material Components where this commonly happens, for example:

Buttons
TextFields
Sheets

We will add more components to this list in the future. These changes provide opinionated defaults to help your apps adapt and look better out of the box on large screen devices. Find more information about using size constraints with components in the Material Design guidelines.

Most foreground UI elements should have a maximum width value.

WindowManager Jetpack library

Beyond component updates to help you scale your UI, we also have the WindowManager Jetpack library to help you build better experiences on these devices. This library is now available in alpha and it provides a common API surface for supporting different device types, starting with foldables and tablets.

You can use WindowManager to detect display features such as folds or hinges. It also gives information about how the display feature affects your app, so you can create an optimal experience. For example, reacting to the foldable device state changes when the device is folded into tabletop mode while the user is watching a video.

Applications should seamlessly adapt to a growing number of device configurations.

WindowManager also provides a couple of convenience methods to retrieve the current and maximum WindowMetrics information in a backward compatible way, starting from API level 14.

Platform changes

Display API deprecations

Your app needs to determine the screen or display size in order to render content appropriately for each device. With the introduction of the WindowMetrics API, a number of methods related to display size have been deprecated. For a backwards-compatible replacement, you should use the Window Manager Jetpack library.

Exclusive resources

Android 10 introduced the possibility to have multiple resumed apps running at the same time, with a single “top resumed” application. Most applications benefit from this change without the need of updates. The most notable exception is if your application uses an exclusive resource like the microphone or the camera. See our previous blog post for more details.

Case studies

Optimizing your app for large screens can improve the experience for your users, as well as deliver on business results. We’re seeing an increased number of apps take advantage of the opportunities with large screens on Google Play. As an example, Google Duo implemented tablet and foldable support to enhance their user experience, and saw an increase in app ratings and user engagement.

Google Duo's optimized experience for foldable devices, such as the Samsung Galaxy Z Fold2

In addition to Google Duo's enhanced user experience, we've modernized many additional apps to use adaptive layouts so they can take advantage of large screens and foldable devices:

Chrome added improved tab navigation for larger screens
YouTube redesigned its UI to improve usability in foldable devices
Google Photos displays more UI elements, like a search bar, in larger screens
Google Calendar provides a more ergonomic UI in larger screens

Learn more

To learn more about foldables and large screen devices, see the following resources:

Source: Android Developers Blog

What’s new for Android developers at Google I/O

Posted by Karen Ng, Director, Product Management & Jacob Lehrbaum, Director of Developer Relations, Android & Play

Android 12: one of the biggest design updates ever.

Jetpack Compose: get ready for 1.0 in July!

Android Studio Arctic Fox: Design, Devices, & Developer Productivity!

Kotlin: the most used language by professional Android devs

Android Jetpack: write features, not boilerplate

Now is the time: a big step for Wear

Tapping the momentum of larger screens, like tablets, Chrome OS and foldables

Google Duo's optimized experience for foldable devices

Source: Android Developers Blog

High engagement, larger screens: How Android developers can reach users on any device

Posted by Allan Livingston, Product Management Director, Chrome OS App Ecosystem

Android fuels mobile apps on devices that range far beyond your typical small-screen smartphone, from new Chromebooks like the lightweight, high-performance Google Pixelbook Go to multi-display devices and foldable phones like the Samsung Galaxy Fold. Not to mention the more than 175M Android tablets that have the Google Play store installed.¹

These large-screen devices set the stage for more engaging and visually immersive experiences, whether by creating a larger canvas for creativity or by giving users faster, more flexible ways to work. As we’ve continued to prioritize large-screen devices with OEM partners like Samsung, Asus, and Lenovo, we’ve been able to expand our reach to a huge new audience of users.

During the week of Black Friday in 2018, 1 in 3 notebooks sold in the U.S. were Chromebooks.² Chromebook unit sales also increased 22% YoY, while the rest of the notebook category decreased -6.1%.³And we’re not just reaching more users — we’re reaching more engaged users. In fact, in just the last year, the total amount of time spent in Android apps on Chrome OS has grown 4X.⁴

By making adjustments for larger screens, you can provide richer experiences across all these devices and tap into a wider audience of app users. Development teams around the world — including Adobe Lightroom, Evernote, and Gameloft, among many others — have already seen some incredible results:

App developers driving engagement on larger screens

With the goal of allowing users to play any video file, anywhere, on any device or screen size, the developers at VideoLAN project decided to adapt VLC — an open source, cross-platform multimedia player — for all screens. The team started by adding keyboard and mouse support before designing multiple versions of the layout to allow users to easily scale and resize the app.

Users can now enjoy the same immersive experience across a range of different devices and form factors, and VideoLAN has already received overwhelmingly positive feedback from users around the world.

War Robots — a 12-player real-time battle game developed by Pixonic — was originally designed for early-generation phones. The team enabled windowed gameplay so users could play in one window while watching their favorite streamers or upgrading their robots in another, created new tutorials and controls that appear whenever players switch between desktop and tablet mode, and added support for keyboard and mouse input.

More than 100,000 players have already played War Robots on Chrome OS since Pixonic rolled out the latest optimizations, which made War Robots’ battles even more thrilling and engaging on larger screens, and Pixonic has seen 25% longer user sessions on Chromebooks as a result.

Is your app optimized for large-screen devices? Here are a few things to consider:

1) Laptop and tablet mode
Test your core app functions to make sure everything works smoothly without crashing as users switch between different modes.

2) Window management and layout
Support multi-window mode and free-form window resizing, and be sure to design optimized layouts for both landscape and portrait orientations. Set up your app to correctly handle configuration changes to avoid crashes when people rotate their devices.

3) Keyboard and mouse input
Make sure your app is fully functional without touch input, and add support for keyboards, mice, and game controllers (if applicable).

4) Hardware support
If you’re using NDK, be sure to support x86 (32 and 64bit) ABIs to ensure the highest possible performance.

Build, test, and run Android apps on a Chromebook

From the start, our goal has been to make the Chromebook a simple, secure, and speedy environment for everyone. The launch of Linux (Beta) on Chrome OS allowed Android developers to build and test apps with a Chromebook. And earlier this year at I/O, we announced that Android Studio 3.5 now fully supports Chrome OS with a simple one-click installation.

Since then, we’ve been working on a few improvements that make Chromebooks an even better place for safe and seamless Android app development. Let’s start with the biggest one:

Deploying an app directly to Chrome OS to enable full Android development
In the past, you could only test your apps by deploying them to Android phones. With Chrome OS’s upcoming M80 release, you’ll be able to deploy Android apps directly to your Chromebook. That way, you can develop and test your app on the same machine, all without a connected device or needing to put your laptop in developer mode. Developers can start testing this feature in developer channel in November.

GPU acceleration for a snappier, jank-free UI (now in beta channel)
We’ve enabled GPU support to reduce latency and deliver a snappier UI. That goes for developer apps such as Android Studio, Unity Editor, or Visual Studio Code. And for developers who also work on web apps, GPU acceleration means faster testing with Chrome Canary or Firefox.

Container backup and restore to easily move between devices
Previously, Linux files and apps were tied entirely to the device — if you lost your device, you lost all the work inside of it. Now, Chrome OS’s container-based architecture allows you to pack up your entire workspace and export it to external storage or Drive. The backup file can be restored at any point, either on the same machine — which is helpful when jumping back to a previous state — or to move to another Chromebook.

You can now find import and export buttons in your Linux settings.

Picture-in-picture (PiP) support

If you’ve built PIP support into your Android apps, you’ll see that function work seamlessly in Chrome OS in 2020. But you can start testing this feature now by enabling PiP in Android settings → Developer options.

Build your apps with larger screens in mind

With millions of users on Chromebooks, tablets, foldables, and now multi-display devices, designing app experiences with larger screens in mind is crucial. Seize this opportunity to engage more users by optimizing your existing apps to work great across all screens. And the latest Linux features on Chrome OS give you the power to use a single machine to build and run Android apps. Don’t hesitate to take action to ensure your apps work seamlessly on larger screens with Linux on Chrome OS.

Sources

1. The number of tablets only accounts for devices that have the Google Play Store installed (e.g., excluding tablets in China); the actual number of tablets capable of running Android applications is much larger.

2. The NPD Group, Inc., Retail Tracking Service, U.S., Notebook Computers, Chrome OS, based on units, Nov. 18, 2018–Nov. 24, 2018 vs. Nov. 19, 2017–Nov. 25, 2017.

3. The NPD Group, Inc., U.S. Retail Tracking Service, Notebook Computers, based on units, Sept. 2018–Aug. 2019. Sales are adjusted for 5 weeks in Jan. 2018 vs. 4 weeks in Jan. 2019.

4. Google Internal Data, March 2018–March 2019.

Source: Android Developers Blog

Bring Your Apps into the Classroom, with Google Play for Education

Posted by Shazia Makhdumi, Head of Strategic EDU Partnerships, Google Play team

Google Play for Education has officially launched. It’s an extension of Google Play that’s designed for schools, simplifying discovery of educational apps and enabling developers and content providers to reach K-12 educators in the U.S. It offers bulk purchasing with purchase orders and instant distribution of educational apps, videos and other educational content to students' Android tablets via the cloud. Google Play for Education helps your apps gain visibility with the right audiences, without having to knock on school doors.

If you've built an Android app that would be awesome for schools—or even have an idea for one—now's the time to jump in. We'll put you one click away from getting purchased and installed by entire school districts. Class Dojo, Explain Everything, Nearpod, and Socrative are already getting discovered in Google Play for Education.

How to join Google Play for Education

If you already have an educational Android app you can use the Google Play Developer Console to mark your apps for inclusion in Google Play for Education. Marking your app identifies it as suitable for the US K-12 educational market and queues it for educator approval. These educators perform a first-pass qualification of apps, assigning the appropriate subject, grade, and common core standards metadata, while evaluating if the app meets the Google Play for Education criteria for classroom use.

Designing great apps for classrooms

High quality apps are top priority for teachers. Whether you already have an existing K-12 educational app or are looking to build one, take a look at our detailed requirements and guidelines—which we have compiled for you based on educator feedback—to ensure your app is appropriate for a K-12 environment. Also ensure that your app is optimized for both 7” and 10” Android tablets. Then, upload your new or updated app through the Developer Console, opt in to Google Play for Education, and publish. We will email you when your app has been evaluated.

For more information, please visit the Google Play for Education pages on the Android developer site. We are excited to be supporting schools to bring the best content and tools to their students. We look forward to seeing your app on Google Play for Education.

Join the discussion on

+Android Developers