Tag Archives: Android

Implementing Dynamic Color: Lessons from the Chrome team

Posted by Rebecca Gutteridge, Developer Relations Engineer on Android

Introduction

With the release of Android 12 and Material You, we provided documentation and guidance on dynamic color foundations, how to implement dynamic color in Jetpack Compose and a getting started codelab. But creating a scalable, personalized, and accessible app with dynamic color can feel like a daunting task. We talked to designers and developers on Google Chrome, and they offered to share some tips on how they approached it at scale for their Android app. Here’s what they suggest if you are considering adopting dynamic color in your app.

Where to start

Start by reviewing all your current screens in your app and identify your current colors, themes and surfaces. Chrome kicked off a design review and evaluated their color scheme. Material 3 encourages designers and developers to use color tokens which enable flexibility and consistency across an app by allowing designers to assign an element's color role in a UI, rather than a set value. This is particularly powerful when considering designing for light and dark themes and dynamic color.

Figure 1 : An example surface for Chrome, the Tab Switcher, identifying the color token for each element

Your app may already have a color token system, so reviewing how the new Material You dynamic color enabled color scheme matches your previous naming convention is an important exercise. Engineering should align with UX to review the new color token system with your mocks. This is also a good opportunity to review your current colors.xml, themes.xml and styles.xml.In particular check that your app correctly differentiates between Styles and Themes as well as correctly extending from base themes. It is also worth reviewing if there are redundant colors in your existing scheme or an opportunity to make a more consistent color scheme throughout your app. Dynamic color implementation with Compose is also available.

Accessibility

Ensuring your app’s color system is accessible is critical for designing for everyone and creating products that are inclusive to the widest possible audience. Dynamic color is committed to guaranteeing that the color selection model has accessibility requirements built in. Material 3 color schemes are defined by tonality rather than hue or hex value, this system of tonal palettes is central to making any color system accessible by default. Using a minimum 60 luminance spread in color pairings provides enough contrast to ensure accessibility standards.

Figure 2 : Combining color based on tonality, rather than hex value or hue, is one of the key systems that make any color output accessible.

Phase approach

When looking at implementation, consider this upgrade as a phased approach if needed, targeting the primary surfaces first and leveraging that dynamic color can be applied at a per activity level. This was how Chrome was able to update their app and used it as an opportunity to migrate some of their older UI app compat components to the modern Material 3 components, such as Top app bar.

How to support custom colors

Your app may have custom colors or brand colors that you do not want to change with the user’s preference. These can simply be added additionally as you are building out your color scheme. Alternatively you can import additional colors to extend your color scheme using the Material Theme Builder to create a unified color system. The theme builder includes a color harmonization feature that shifts the tone of a custom color to ensure that visual balance and accessible contrast is achieved when combined with user-generated colors.

Figure 3: Understand how to harmonize custom colors with the Material guidance.

For Chrome, here is a deep dive into two examples of where protected colors are important for them and how they approached it.

Publisher colors

It is important that Chrome allows for brands to keep their known colors and not impact that functionality when adopting dynamic color.

Publishers have the ability to set a publisher color using a metadata element in their html. The top toolbar is controlled using a decision tree to programmatically determine the toolbar color and icon color based on a series of cascading rules:

Incognito mode has the highest priority. If Incognito is enabled, the toolbar and icon colors follow the dark baseline palette.
For night theme, toolbar and icon colors follow the dark dynamic theme rather than the publisher color to ensure a consistently dark UI.
For day theme, the toolbar color is set to the publisher color, the icon color is either white or gray based on whether the publisher color is a dark or light color via util method.
If the publisher color is too bright or not specified, Chrome defaults to the light dynamic theme.

Incognito

In Incognito mode, the dark gray color scheme has a semantic importance and reassurance for users. Chrome decided to preserve and leverage their existing color system and not change it dynamically.

Figure 4: Incognito mode remains the same

To achieve this, Chrome defined non adaptive colors that map to hex values and adaptive colors that map to different non adaptive colors for day/night mode. For incognito mode, Chrome uses the dark non adaptive colors as they are easily recognized by the users as incognito. With these adaptive colors, Chrome created a baseline theme.

The table below shows what their background colors look like after applying dynamic colors:

Table showing what background colors look like after applying dynamic colors

Themes and Theme Overlays

One thing to consider for adhering to theme best practices, is to leverage Theme Overlays properly. The Chrome team used this opportunity to refactor their themes and leveraged the power of Theme Overlays for a given activity. At times Chrome saw that full themes were being used where a ThemeOverlay would be more appropriate. Dynamic color and Material3 encourages better code hygiene.

Take a look at this example, previously the theme for full screen dialogs inherited from a full theme. This overrode all the attributes from the activity theme, undoing the dynamic colors or any overrides that are applied at the activity level. With the dynamic color work, the team became more deliberate in how they define and use their theming.

Previously:

    <style name="Base.Theme.Chromium.Fullscreen" parent="Theme.BrowserUI.DayNight">
    <item name="windowActionBar">true</item>
          <item name="colorPrimary">...</item>
          <item name="colorAccent">...</item>
    </style>

Now:

    <style name="Base.ThemeOverlay.BrowserUI.Fullscreen" parent="">
    <item name="android:windowContentTransitions">false</item>
    </style>

Recommendations from Google Chrome designers

This section shares some key lessons that Chrome’s designers applied to successfully create an intentional and unified theme

Create a unified design system: Material 3 and dynamic color gives the opportunity to reconcile your app’s themes. For Chrome that meant reconciling their light and dark theme and removing fragmentation based on elevation.
Identifying how to migrate existing color system: Understand the role of your current color system and tokens, if applicable, and how they map onto the M3 color tokens.
Use accent colors meaningfully: Material 3’s accented color tokens are incredibly powerful and useful, iterate on how best to use them.
Phased approach: Focus on a few surfaces first. Dynamic color is increasingly part of the user’s expectation of their device, so work out which surfaces make sense to adopt first and then iterate and expand to more surfaces.
Work closely with your engineers from the beginning: Share designs as soon as you have them with your engineers. Chrome designers asked questions to understand how Chrome was built so they could establish how color would be applied and which components might be affected. This will help you make better informed decisions on which surfaces/components are updated since there could be many dependencies in your app.
Create custom tokens: If you need to use dynamic colors that are not part of the out of the box color system, create a custom color token that extends your color theme.

Recommendations from Google Chrome developers

This section shares some key lessons that Chrome’s developers applied to successfully migrate

Have a rigorous theme code hygiene: Create a baseline set of colors without dynamic for instances where dynamic color is not applied, eg, incognito mode and then extend with theme and theme overlays.
Understand how to use surface colors: Surfaces are treated with “elevation” to allow differentiation from the background and layered elements like app bars, and other navigation elements; this may be a paradigm shift for some apps. Surface colors are calculated at runtime, so there is no resource/color/macro to retrieve them currently. Chrome decided to create a utility method to calculate surface colors using `ElevationOverlayProvider`. However, this is only available to use programmatically while we also needed to implement dynamic color for many layouts in bulk. For this purpose, they created a custom Drawable that can draw a surface color based on a provided elevation value. One drawback of this approach is that a legacy pre-dynamic colors version of each drawable must be maintained for compatibility with old Android versions.
Importance of using Activity context: It’s important to use the Activity context to inflate views as the Activity has the theme with the dynamic color overlay applied.
Choice of method to get colors: Usage of ‘Resources#getColor(int)’ was very common in Chrome’s codebase because they needed to support older Android versions. However, to support dynamic color, the `#getColor` method should be able to resolve the color resources against the theme. So, Chrome migrated the `Resources#getColor` calls to `Context#getColor`.
Macros: Chrome uses semantic color names to have a unified color system throughout the app. Before the dynamic color adoption, a semantic color would look something like this:
@color/default_text_color_light: Color used for primary text

→ @color/default_text_color_dark/@color/default_text_color_light (adaptive to night mode)

→ @color/modern_grey_900/@color/modern_white

→ #1F1F1F / #FFFFFF

Your app may already have a semantic color system and so migrating adds additional considerations. For Chrome they wanted to preserve their semantic colors. In collaboration with UX, they translated the existing color palette to the Material color roles/attributes. Their first idea was to point to these attributes from the existing semantic colors. For example, @color/default_text_color from the example above would look like this: <color name="default_text_color">?attr/colorOnSurface</color>. However, the @color resource cannot point to an ?attr. The next idea was to convert all semantic `@color`s to `?attr`s with the same names. This approach also caused issues as they needed to add all the attributes to their themes and there are many activities, themes and entry points to Chrome, so it would be challenging to maintain. Finally, they adopted the newly introduced <macro> tag. Macros are much like C/C++ macros but for Android resources: they are replaced with whatever they point to at build time. So semantic colors became semantic macros, for example, <macro name="default_text_color">?attr/colorOnSurface</macro>. This made it possible to implement dynamic colors at bulk. One limitation of macros is that they cannot be accessed programmatically, but Chrome added static utility methods to work around this. The macro tag is now available in Android Studio Canary.

Dynamic color is coming to more Android 12 phones globally, including devices by Samsung, OnePlus, Oppo, Vivo, realme, Xiaomi, Tecno, and more! As you work with dynamic color in your app, we’d love to get your feedback via the Material Android issue tracker. Happy coloring!

Source: Android Developers Blog

Driving growth in the Middle East

The Nest is an online store that offers curated handcrafts from Egypt, from home accessories to fashion and furniture. When the pandemic started, founders Dina and Omar had to close their physical showroom, which used to drive 90% of their sales. They listed their business details on Google Maps and Search, promoted their products online and revamped their website which, in less than a year, became their main source of revenue.

According to a new report published by Public First research agency and commissioned by Google, our products and tools in the UAE, Egypt and Saudi Arabia helped businesses to adapt during the pandemic and helped people sharpen their skills and find jobs.

The report shows 45% of people in Egypt last year used Google Maps to find a local business and 52% of businesses in Saudi Arabia reported an increased proportion of their customers coming from online search or search advertising.

Since opening our first office in the Middle East and North Africa 13 years ago, Google has been actively supporting local businesses and developers, YouTube content creators, and publishers. Public First estimates that last year Google products like Search, YouTube, Android and Google Ads drove 12.2 billion SAR [3.2 billion USD] to the Saudi economy, 11.3 billion AED [3 billion USD] to the UAE economy and 11.2 billion EGP [600 million USD] to Egypt's economy.

Growing developers and creators

Manal, Saudi YouTube creator, shows how she tailors trousers on her YouTube channel

Manal, DIY content creator on YouTube in Saudi Arabia. Photo credit: Manal’s YouTube page

Manal, from Jeddah in Saudi Arabia, has a passion for DIY in fashion and home improvement. She started her YouTube channel to share her knowledge in upcycling dresses and scarves to make trousers, and repainting her room for Ramadan. Manal’s work has inspired others, and her community often share their own versions of her designs and ask for DIY tips. When she built her channel during the pandemic, her subscribers grew by over 300%. Manal is one of many talented creators in Saudi Arabia growing their business on YouTube. In fact, the percentage of YouTube channels in Saudi Arabia making six figures or more in revenue is up more than 20% year over year. That's a sign of steady growth in Saudi Arabia’s YouTube creator community.

Founder of Lamsa, Badr Ward, stands, smiling, with his arms folded

Badr Ward, founder of Lamsa World, an Arabic educational platform in the UAE. Photo credit: Hub71

Lamsa World is an educational platform in Arabic for children. It has interactive courses in math, science, language, arts and more. Badr Ward, the Dubai-based founder, wanted to help his children watch more educational content in Arabic, which was sparse and not always engaging. Badr and his team took part in the Google Accelerator Program in Dubai last year and, with the help of mentors, tested different sign-up options and experimented with different content formats. This led to a significant increase in the website's sign-up rates and a 300% increase in Arabic content downloads.

Unlocking skills and jobs

Since its launch in 2018, Maharat min Google, Google's digital skills program in Arabic, has trained 1.5 million people in the Middle East and North Africa. And in October 2020, Google announced a $13 million USD fund for digital tools, training programs, mentorship and financial grants to support businesses and job seekers in the Middle East and North Africa during the pandemic. Following Google's mentorship program with Mercy Corps, 50% of trainees said that they found a job, accelerated their career or grew their business by hiring new staff or increasing revenue.

Google Search also played a big role in helping people in the region access information and skills last year. For example, 85% of people in the UAE said they used Search to learn a new skill.

People looked for jobs too. Every month, around 11 million women in Egypt go to Search to look for a job. In Saudi Arabia, 1.8 million people use Search to prepare for a job interview. According to the World Economic Forum, many women are contributing to the innovation coming out of the Middle East and North Africa, yet this region continues to have one of the lowest levels of female economic involvement globally.

Public First estimates there are already 85,000 Android-based developer jobs in Egypt and 50,000 in the UAE. In Saudi Arabia, the total number of developers making USD 10,000 per month on Google Play grew by 16% last year.

We are proud that people in the Middle East and North Africa are able to unlock opportunities for themselves with the help of Google products and tools. The region is young, smart and digital, and Google is committed to doing more to help entrepreneurs, local business owners, developers and content creators get the skills they need to build and grow their digital businesses.

If you want to understand more about Google's impact in the Middle East and North Africa, and the methodology behind the report, visit the links below:

UAE: googlemena.publicfirst.co/uae
Saudi Arabia: googlemena.publicfirst.co/saudiarabia
Egypt: googlemena.publicfirst.co/egypt

Source: The Official Google Blog

Modern Android Development at Google I/O ‘22

Posted by Nick Butcher, Developer Relations Engineer

Our goal is to make developing beautiful and engaging Android apps as fast and easy as possible. We want to take on the complex parts of building apps so that you can focus on your app’s features and deliver high quality experiences to your users.

We call this approach Modern Android Development (or MAD for short!) and deliver it through a suite of tools, libraries and guidance. At Google I/O we announced a number of updates and additions to our MAD offerings; here’s a recap of the three largest announcements.

#1 Compose 1.2 Beta

Jetpack Compose 1.2 reaches the first Beta, which means the API is stable. We continue to build out our roadmap, bringing 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 counts in the Layout Inspector and Animation Preview. Learn more about how developers like Airbnb are improving their productivity with Jetpack Compose, and check out what else is new in Compose.

#2 Baseline Profiles

Baseline profiles allow you to embed a profile to guide the Android Runtime about which code paths should be pre-compiled rather than interpreted, which could dramatically impact critical user journeys like app startup. This is especially significant when using unbundled libraries like Jetpack Compose which don’t benefit from optimizations in platform code.

Many Jetpack libraries (including Jetpack Compose) already ship baseline profiles, but you can learn how to add them to your own apps and libraries to boost their performance. We've seen up to 40% faster app startup times thanks to adding baseline profiles alone, no other code changes required!

#3 Live Edit

With Live Edit you can edit composables and view those changes in real time, on the Compose Preview or on physical devices or emulators, enabling rapid iteration. Live Edit is an opt-in experimental feature in Android Studio Electric Eel, with a number of limitations. Please try it out and provide your feedback.

Those were the top three announcements about Modern Android Development at Google I/O. To learn more, check out the full playlist of talks and workshops.

Source: Android Developers Blog

Making Android more accessible for braille users

Editor’s note: Today is Global Accessibility Awareness Day, and we’ll be sharing more on how we’re partnering with people with disabilitiesand what we’re doing to make education more accessible.

The heart of our mission at Google is making the world’s information truly accessible. But the reality is we can only realize this mission with the help of the community. This year at I/O, we announced one more step in the right direction, thanks to feedback and help from our users: We’re making it easier for braille readers to use Android. Available in our next Android 13 Beta in a few weeks, we are beginning to build out-of-the-box support for braille displays in Talkback, our screen reader within Android.

A refreshable braille display is an electro-mechanical device that creates braille patterns by raising rounded pins through holes in a flat surface. Braille-literate computer users use the braille display to touch-read braille dots representing text. With the display, you can also type out braille. These devices help people with deafblindness access mobile phones and people with blindness use their phones silently. Previously, people connected their Android devices to braille displays using the BrailleBack app, which required a separate download from the Play Store, or used a virtual keyboard within Talkback instead of a physical device.

With this new update, there are no additional downloads necessary to use most braille displays. People can use braille displays to access many of the same features available with Talkback. For instance, you can use display buttons to navigate your screen and then do activities like compose an email, make a phone call, send a text message or read a book.

There are also new shortcuts that make it easier to use braille displays with Talkback. Now there are shortcuts for navigating so it’s easier to scroll and move to the next character, word or line. There are also shortcuts for settings and for editing, like jumping to the end of documents or selecting, copying and pasting.

You can sign up for the Android beta program to try out Talkback 13 in the next beta release.

We are grateful to the community for their ongoing feedback that makes features like these possible. This is just the first step forward in developing this integration, and we can’t wait to do even more to expand the feature and to create even more related capabilities.

Source: The Official Google Blog

Boost the security of your app with the nonce field of the Play Integrity API

Posted by Oscar Rodriguez, Developer Relations Engineer

With the recent launch of the Play Integrity API, more developers are now taking action to protect their games and apps from potentially risky and fraudulent interactions.

In addition to useful signals on the integrity of the app, the integrity of the device, and licensing information, the Play Integrity API features a simple, yet very useful feature called “nonce” that, when correctly used, can further strengthen the existing protections the Play Integrity API offers, as well as mitigate certain types of attacks, such as person-in-the-middle (PITM) tampering attacks, and replay attacks.

In this blog post, we will take a deeper look at what the nonce is, how it works, and how it can be used to further protect your app.

What is a nonce?

In cryptography and security engineering, a nonce (number once) is a number that is used only once in a secure communication. There are many applications for nonces, such as in authentication, encryption and hashing.

In the Play Integrity API, the nonce is an opaque base-64 encoded binary blob that you set before invoking the API integrity check, and it will be returned as-is inside the signed response of the API. Depending on how you create and validate the nonce, it is possible to leverage it to further strengthen the existing protections the Play Integrity API offers, as well as mitigate certain types of attacks, such as person-in-the-middle (PITM) tampering attacks, and replay attacks.

Apart from returning the nonce as-is in the signed response, the Play Integrity API doesn’t perform any processing of the actual nonce data, so as long as it is a valid base-64 value, you can set any arbitrary value. That said, in order to digitally sign the response, the nonce is sent to Google’s servers, so it is very important not to set the nonce to any type of personally identifiable information (PII), such as the user’s name, phone or email address.

Setting the nonce

After having set up your app to use the Play Integrity API, you set the nonce with the setNonce() method, or its appropriate variant, available in the Kotlin, Java, Unity, and Native versions of the API.

Kotlin:

val nonce: String = ...

// Create an instance of a manager.
val integrityManager =
    IntegrityManagerFactory.create(applicationContext)

// Request the integrity token by providing a nonce.
val integrityTokenResponse: Task<IntegrityTokenResponse> =
    integrityManager.requestIntegrityToken(
        IntegrityTokenRequest.builder()
             .setNonce(nonce) // Set the nonce
             .build())

Java:

String nonce = ...

// Create an instance of a manager.
IntegrityManager integrityManager =
    IntegrityManagerFactory.create(getApplicationContext());

// Request the integrity token by providing a nonce.
Task<IntegrityTokenResponse> integrityTokenResponse =
    integrityManager
        .requestIntegrityToken(
            IntegrityTokenRequest.builder()
            .setNonce(nonce) // Set the nonce
            .build());

Unity:

string nonce = ...

// Create an instance of a manager.
var integrityManager = new IntegrityManager();

// Request the integrity token by providing a nonce.
var tokenRequest = new IntegrityTokenRequest(nonce);
var requestIntegrityTokenOperation =
    integrityManager.RequestIntegrityToken(tokenRequest);

Native:

/// Create an IntegrityTokenRequest object.
const char* nonce = ...
IntegrityTokenRequest* request;
IntegrityTokenRequest_create(&request);
IntegrityTokenRequest_setNonce(request, nonce); // Set the nonce
IntegrityTokenResponse* response;
IntegrityErrorCode error_code =
        IntegrityManager_requestIntegrityToken(request, &response);

Verifying the nonce

The response of the Play Integrity API is returned in the form of a JSON Web Token (JWT), whose payload is a plain-text JSON text, in the following format:

{
  requestDetails: { ... }
  appIntegrity: { ... }
  deviceIntegrity: { ... }
  accountDetails: { ... }
}

The nonce can be found inside the requestDetails structure, which is formatted in the following manner:

requestDetails: {
  requestPackageName: "...",
  nonce: "...",
  timestampMillis: ...
}

The value of the nonce field should exactly match the one you previously passed to the API. Furthermore, since the nonce is inside the cryptographically signed response of the Play Integrity API, it is not feasible to alter its value after the response is received. It is by leveraging these properties that it is possible to use the nonce to further protect your app.

Protecting high-value operations

Let us consider the scenario in which a malicious user is interacting with an online game that reports the player score to the game server. In this case, the device is not compromised, but the user can view and modify the network data flow between the game and the server with the help of a proxy server or a VPN, so the malicious user can report a higher score, while the real score is much lower.

Simply calling the Play Integrity API is not sufficient to protect the app in this case: the device is not compromised, and the app is legitimate, so all the checks done by the Play Integrity API will pass.

However, it is possible to leverage the nonce of the Play Integrity API to protect this particular high-value operation of reporting the game score, by encoding the value of the operation inside the nonce. The implementation is as follows:

The user initiates the high-value action.
Your app prepares a message it wants to protect, for example, in JSON format.
Your app calculates a cryptographic hash of the message it wants to protect. For example, with the SHA-256, or the SHA-3-256 hashing algorithms.
Your app calls the Play Integrity API, and calls setNonce() to set the nonce field to the cryptographic hash calculated in the previous step.
Your app sends both the message it wants to protect, and the signed result of the Play Integrity API to your server.
Your app server verifies that the cryptographic hash of the message that it received matches the value of the nonce field in the signed result, and rejects any results that don't match.

The following sequence diagram illustrates these steps:

Implementation diagram for encoding the value of the operation inside the nonce. Steps outlined in the body of the blog.

As long as the original message to protect is sent along with the signed result, and both the server and client use the exact same mechanism for calculating the nonce, this offers a strong guarantee that the message has not been tampered with.

Notice that in this scenario, the security model works under the assumption that the attack is happening in the network, not the device or the app, so it is particularly important to also verify the device and app integrity signals that the Play Integrity API offers as well.

Preventing replay attacks

Let us consider another scenario in which a malicious user is trying to interact with a server-client app protected by the Play Integrity API, but wants to do so with a compromised device, in a way so the server doesn’t detect this.

To do so, the attacker first uses the app with a legitimate device, and gathers the signed response of the Play Integrity API. The attacker then uses the app with the compromised device, intercepts the Play Integrity API call, and instead of performing the integrity checks, it simply returns the previously recorded signed response.

Since the signed response has not been altered in any way, the digital signature will look okay, and the app server may be fooled into thinking it is communicating with a legitimate device. This is called a replay attack.

The first line of defense against such an attack is to verify the timestampMillis field in the signed response. This field contains the timestamp when the response was created, and can be useful in detecting suspiciously old responses, even when the digital signature is verified as authentic.

That said, it is also possible to leverage the nonce in the Play Integrity API, to assign a unique value to each response, and verifying that the response matches the previously set unique value. The implementation is as follows:

The server creates a globally unique value in a way that malicious users cannot predict. For example, a cryptographically-secure random number 128 bits or larger.
Your app calls the Play Integrity API, and sets the nonce field to the unique value received by your app server.
Your app sends the signed result of the Play Integrity API to your server.
Your server verifies that the nonce field in the signed result matches the unique value it previously generated, and rejects any results that don't match.

The following sequence diagram illustrates these steps:

Implementation diagram for assigning a unique value to each response, and verifying that the response matches the previously set unique value. Steps outlined in the body of the blog.

With this implementation, each time the server asks the app to call the Play Integrity API, it does so with a different globally unique value, so as long as this value cannot be predicted by the attacker, it is not possible to reuse a previous response, as the nonce won’t match the expected value.

Combining both protections

While the two mechanisms described above work in very different ways, if an app requires both protections at the same time, it is possible to combine them in a single Play Integrity API call, for example, by appending the results of both protections into a larger base-64 nonce. An implementation that combines both approaches is as follows:

The user initiates the high-value action.
Your app asks the server for a unique value to identify the request
Your app server generates a globally unique value in a way that malicious users cannot predict. For example, you may use a cryptographically-secure random number generator to create such a value. We recommend creating values 128 bits or larger.
Your app server sends the globally unique value to the app.
Your app prepares a message it wants to protect, for example, in JSON format.
Your app calculates a cryptographic hash of the message it wants to protect. For example, with the SHA-256, or the SHA-3-256 hashing algorithms.
Your app creates a string by appending the unique value received from your app server, and the hash of the message it wants to protect.
Your app calls the Play Integrity API, and calls setNonce() to set the nonce field to the string created in the previous step.
Your app sends both the message it wants to protect, and the signed result of the Play Integrity API to your server.
Your app server splits the value of the nonce field, and verifies that the cryptographic hash of the message, as well as the unique value it previously generated match to the expected values, and rejects any results that don't match.

The following sequence diagram illustrates these steps:

implementation diagram for combining both protections. Steps outlined in the body of the blog.

These are some examples of ways you can use the nonce to further protect your app against malicious users. If your app handles sensitive data, or is vulnerable against abuse, we hope you consider taking action to mitigate these threats with the help of the Play Integrity API.

To learn more about using the Play Integrity API and to get started, visit the documentation at g.co/play/integrityapi.

Source: Android Developers Blog

Airbnb uses Jetpack Compose to empower devs to do their best work

How Compose enables Airbnb to create better host and guest experiences

Since 2007, Airbnb has grown to connect more than 4 million hosts with more than 1 billion guests across the globe. One of the reasons behind the app’s success is that its developers aim to achieve engineering excellence by focusing on two main principles: using technology that sparks innovative development and empowering the engineers behind the work.

Jetpack Compose, Android’s modern UI-building toolkit, directly supports both of Airbnb’s development principles. Compose provided a solid foundation for adaptable, quality engineering and reduced boilerplate code, so developers could focus on delivering a great user experience — and advance their two-fold pursuit of engineering excellence.

Airbnb started testing Compose in 2020 when it was in developer preview. As an early adopter, the Airbnb team was eager use the various new features and simplify their workflow. Now, having gained confidence using Compose in production, Airbnb engineers continue to be satisfied with how it improved their development process.

Equipping engineers for success

Compose’s deterministic testing helped ensure Airbnb’s engineers had tight control over the UI tests they ran and eliminated common flakiness, thereby strengthening their confidence in the quality of every part of their app and the user experiences they were creating. Engineers can now also use Compose to test animations they previously couldn't.

Similarly, Airbnb developers used Compose to add automated screenshot tests to their codebase. Because they didn’t need to write the code for screenshot testing, engineers could go straight into using it to catch bugs and regressions. This gave them more time to review and guarantee feature functionality and UI appearance across a variety of devices.

Compose is great to use alongside Views. This interoperability made it easy for Airbnb engineers to onboard and test the new UI toolkit at their own pace, so they were able to experience the benefits of Compose without having to migrate entire features.

These engineering improvements gave them the solid technical foundations they needed to serve users in fresh and improved ways.

Engineering efficiencies improve user experiences

Airbnb keeps hosts and guests at the heart of their decisions. The engineering team was excited to adopt Compose when they learned about how it would enable them to more easily and efficiently produce UI, resulting in better experiences for their end users.

Because Compose made Airbnb’s features require significantly less code to write and manage, the Airbnb team boosted their efficiency. All of this meant the team could focus its energy on executing the complex tasks involved in developing the innovative features that could best serve users.

Because their features now require less code, the Airbnb team will be able to slow the growth of their app size in the long run. Providing a smaller app is important to Airbnb as an organization with users across the globe that looks to ensure all hosts and guests can easily download and access their app — especially those with older devices or logging on from countries with high data costs.

Using Compose’s engineering enhancements, the Airbnb team was able to put user needs first.

Improve developer productivity with Compose

Compose simplified UI development to allow Airbnb engineers the freedom to focus on more dynamic and innovative features that benefit the app’s hosts and guests.

Learn how you can improve your team’s productivity with Jetpack Compose.

Source: Android Developers Blog

Airbnb uses Jetpack Compose to empower devs to do their best work

How Compose enables Airbnb to create better host and guest experiences

Equipping engineers for success

These engineering improvements gave them the solid technical foundations they needed to serve users in fresh and improved ways.

Engineering efficiencies improve user experiences

Using Compose’s engineering enhancements, the Airbnb team was able to put user needs first.

Improve developer productivity with Compose

Compose simplified UI development to allow Airbnb engineers the freedom to focus on more dynamic and innovative features that benefit the app’s hosts and guests.

Learn how you can improve your team’s productivity with Jetpack Compose.

Source: Android Developers Blog

Now in Android – a new, open source, real-world sample app

Posted by Paris Hsu, Product & Design, Android and Don Turner, Developer Relations Engineer, Android

The Now in Android app is now on GitHub!

For two years, 'Now in Android' has been a popular blog and YouTube series, providing you with the latest and greatest developer news from the Android team. Starting today, you can check out the alpha version of the Now in Android app on GitHub! 🎉

The app has two goals:

Firstly, it showcases best practices, opinionated designs, and solutions to complex real-world problems which other sample apps don’t handle. It does so with an open source implementation of a real world app.

Secondly, it helps you (the developer) keep up to date with the areas of Android development which interest you most. It is a working app planned for publication on the Play Store.

Now in Android app screen designs

For this first alpha release, the Now in Android app includes:

UI built using Jetpack Compose
Theme components with Material3
Adaptive layouts for different screen sizes
Architecture that follows our official guidance
A reactive programming model with unidirectional data flow, implemented using Kotlin Flows
Room and Proto DataStore for local data storage, offline first
Remote/local data synchronization scheduled using WorkManager with exponential backoff

As well as these features, we are also documenting the learning journeys we took to certain decisions with the app's design and implementation. Check out our first journey on the app's Architecture here.

image showing how the Now in Android app adapts based on device screen size

The Now in Android screens adapt based on device screen size

Since this is an alpha release, we expect that there will be bugs and missing features, and we would greatly appreciate your feedback. We have some exciting features planned, such as user authentication and loading data from a real backend. We can’t wait for you to check out the app and let us know what you think!

Finally, if you want to learn about the tools we used to build the app and how we target multiple screen sizes, check out these talks from this year's Google I/O:

Source: Android Developers Blog

What’s new with Android for Cars

Posted by Jennifer Chui, Technical Program Manager and Rod Lopez, Product Manager

At Google, our work in cars has always been guided by our vision of creating safe and seamless connected experiences. This work would not be possible without developers like you. We’re excited to share some of our combined accomplishments from this past year, and introduce new updates that will make it easier for you to provide users with an even better experience in the car.

Android Auto continues to grow and scale, with compatible vehicles now numbering over 150 million worldwide. An increasing number are also wirelessly compatible, and with the newly introduced Motorola MA1 adapter, even more drivers now have access to a wireless experience. In addition, our new design for Android Auto brings split-screen functionality to every screen, keeping navigation and media front and center while also providing room for prominent notification widgets.

View of the Android Automotive dashboard

Android Automotive OS with Google built-in also has exciting updates. Beyond the continued expansion of carmakers that are bringing more car models to the market, we’ve also been hard at work enabling more parked experiences to take advantage of the large screens that many AAOS cars offer. From more video streaming apps like Epix Now and Tubi to future features like browsing and cast, there’s much to look forward to, and given minimal effort is required to translate your large screen tablet apps into a parked car experience, it’s now easier than ever to reach users in the car.

We know that developing for cars can be complex, which is why we’re focused on making developing across Android for Cars as easy as possible. We’ve seen strong momentum with our Car App Library with over 200 apps published to date, and beyond enriching the navigation feature set with version 1.3, we’re also excited to share that all developers can now publish apps in supported categories directly to production for both Android Auto and Android Automotive OS. We’ve also created new templates and expanded our supported app categories, adding driver apps like Lyft to the navigation category, and replacing the parking and charging categories with a comprehensive point of interest (POI) category to include apps like MochiMochi and Fuelio.

We’re also introducing several new features to help you build more powerful media apps on Android Auto. Media recommendations working side by side with Google Assistant helps users easily discover and quickly play relevant content based on their preferred music provider at the click of a button. To surface recommendations from your app, integrate with this API.

For long form content such as podcasts and audiobooks, you can now introduce a progress bar that shows how much of the content the user has previously listened to, and with our new single item styling API, you can now assign content items individually as either list or grid as opposed to categorically, to easily combine them in the same content space.

We’re grateful to have you on the journey with us as we seek to create safer, more seamless connected experiences in cars. Be sure to check out our Google I/O technical session above, and as always, you can get help from the developer community at Stack Overflow using the android-automotive and android-auto tags. We can’t wait to see what you build next, and where the road takes you.

Source: Android Developers Blog

What’s new with Google TV & Android TV OS

Shobana Radhakrishnan, Senior Director of Engineering - Google TV

Paul Lammertsma, Developer Relations Engineer

Image of Android and Google TV Iconography

Today, there is more entertainment content available than ever before. In fact, our research shows a third of U.S. households now watch more than 25 hours of TV every week. As the role of TV continues to evolve, it’s our goal to build a tailored TV experience that gives users easy access to the entertainment they love.

We’re excited about the future of Android TV OS, now with over 110 million monthly active devices, including millions of Google TVs. Android TV and Google TV are available on over 300 partners worldwide, including 7 of the 10 largest smart TV OEMs and over 170 pay TV operators. And thanks to the hard work of our developer community, there are more than 10,000 apps available on TV, with more being added everyday.

Since last year’s I/O, we’ve continued our commitment to enable you to build better and more engaging experiences on Android TV OS. In addition to platform updates, new features, like expanded integrations with the Live tab, offer opportunities for users to better engage with your content. And if you haven’t begun using WatchNext API, take a moment to learn how to add it to your app to make your content more discoverable and accessible.

Today, we are introducing new features and tools on Android 13 that focus on overall performance & quality, improve accessibility, and enable multitasking.

Performance & quality: To help build for the next generation of TVs, we’re introducing new APIs to help you better detect a user’s settings and give them the best experience for their device. AudioManager allows your app to anticipate audio routes and precisely understand which playback mode is available. Integrating your app correctly with MessiaSession allows Android TV to react to HDMI state changes in order to save power and signal that content should be paused.
Accessibility: To improve how users interact with their TV, we’ve added support for different keyboard layouts in the InputDevice API. Game developers can also reference keys by their physical location to support different layouts of physical keyboards, such as QWERTZ and AZERTY keyboards. A new system-wide accessibility preference also allows users to enable audio descriptions across apps.
Multitasking: TVs are now used for more than just watching media content. In fact, we often see users taking calls or monitoring cameras in a smart home. To help with multitasking, an updated picture in picture API will be supported in Android 13 with the APIs from core Android. Picture in picture on the TV supports an expanded mode to show more videos from a group call, a docked mode to avoid overlaying content on other apps, and a keep-clear API to prevent overlays from concealing important content in full-screen apps.

Image of Google TV interface with picture of Dune showing

Android 13 Beta for TV is available now, allowing you to test your apps and provide feedback on the latest release. Thank you for your continued support of Android TV OS. We can’t wait to see what amazing and innovative things you continue to build for the big screen.