Beta Channel Update for ChromeOS

The Beta channel is being updated to 108.0.5359.58 (Platform version: 15183.51.0) for most ChromeOS devices. This build contains a number of bug fixes and security updates and will be rolled out over the next couple days.

If you find new issues, please let us know one of the following ways

  1. File a bug
  2. Visit our ChromeOS communities
    1. General: Chromebook Help Community
    2. Beta Specific: ChromeOS Beta Help Community
  3. Report an issue or send feedback on Chrome

Interested in switching channels? Find out how.


Google ChromeOS.

Experts share insights on Firebase, Flutter and the developer community

Posted by Komal Sandhu - Global Program Manager, Google Developer Groups

Rich Hyndman, Manager, Firebase DevRel (left) and Eric Windmill, Developer Relations Engineer, Firebase and Flutter (right)

“Firebase and Flutter offer many tools that ‘just work’, which is something that all apps need. I think you’d be hard pressed to find another combination of front end framework and back end services that let developers make apps quickly without sacrificing quality.” 

moving images of Sparky and Dart, respective mascots for Firebase and Flutter
Among the many inspiring experts in the developer communities for Firebase and Flutter are Rich Hyndman and Eric Windmill. Each Googler serves their respective product team from the engineering and community sides and has a keen eye towards the future. Read on to see their outlook on their favorite Firebase and Flutter tools and the developers that inspire them.

===

What is your title, and how long have you been at Google?

Rich: I run Firebase Developer Relations,, I’ve been at Google for around 11 years

Eric: I’m an engineer on the Flutter team and I’ve been at Google for a year.


Tell us about yourself:

Rich: I’ve always loved tech, from techy toys as a kid to anything that flies. I still get tech-joy when I see new gadgets and devices. I built and raced drones for a while, but mobile/cell phones are the ultimate gadget for me and enabled my career.

Eric: I’m a software engineer, and these days I’m specifically a Developer Relations Engineer. I’m not surprised I’ve ended up here, as I like to joke “I like computers but I like people more.” Outside of work, most of my time is spent thinking about music. I’m pretty poor at playing music, but I’ve always consumed as much as I could. If I had to choose a different job and start over, I’d be a music journalist.


How did you get started in this space?

Rich: I've always loved mobile apps: being able to carry my work in my pocket, play with it, test it, demo it, and be proud of it. From the beginning of my career right up till today, it's still the best. I worked on a few mobile projects pre-Android and was part of an exciting mobile tech startup for a few years, but it was Android that really kick-started my career.

I quickly fell in love with the little green droid and the entire platform, and through a combination of meetups, competition entries and conferences I ended up in contact with Android DevRel at Google.

Firebase is a natural counterpart to Android and I love being able to support developers from a different angle. Firebase also supports Flutter, Web and iOS, Firebase, which has also given me the opportunity to learn more about other platforms and meet more developers.

Eric: I got into this space by accident. At my first software job, the company was already using Dart for their web application, and started rebuilding their mobile apps in Flutter soon after I joined. I think that was around 2016 or 2017. Flutter was still in its Alpha stage. I was introduced to Firebase at the same job, and I’ve used various tools from the Firebase SDK ever since.


What are some challenges that you have seen developers being facing?

Rich: Developers often want to get up and running with new projects quickly, but then iterate and improve their apps. No-code solutions can be great to start with but aren’t flexible enough down the road. A lower-code solution like Firebase can be quick to get started, and it can also provide control. Bringing Flutter and Firebase together creates a powerful and flexible combination.

Eric: Regardless of the technology, I think the biggest challenge developers face is actually with documentation. It doesn’t matter how good a product is if the docs are hard to find or hard to understand. We’ve seen this ourselves recently as Flutter became an “official” supported platform on Firebase in May 2022. When that happened, we moved the documentation from the Flutter site to the Firebase site, and folks didn’t know how to find the docs. It was an oversight on our part, but it’s a good example of the importance of docs. They deserve way more attention than they get in many, many cases.

image of Sparky and Dart, respective mascots for Firebase and Flutter
What do you think is the most interesting or useful resource to learn more about Firebase & Flutter? Is there a particular library or codelab that everyone should learn?

Rich: The official docs have to be first, located at firebase.google.com. We have a great repository of Learning Pathways, including Add Firebase to your Flutter App. We’re also just launching our new Solutions Portal with over 60 solutions guides indexed already.

Eric: If I have to name only one resource, it’d be this codelab: Get to know Firebase for Flutter
But Firebase offers so many tools. This codelab is just an introduction to what’s possible.


What are some inspiring ways that developers are building together Firebase and Flutter?

Rich: We’ve had an interesting couple of years at Firebase. Firebase has always been known for powering real-time data driven apps. If you used a Covid stats app during the pandemic there’s a fair chance it was running on Firebase; there was a big surge of new apps.

Eric: Lately I’ve seen an interest in using Flutter to make 2D games, and using some Firebase tools for the back end of the game. I love this. Games are just more fun than apps, of course, but it’s also great to see folks using these technologies in ways that aren’t the explicit purposes. It shows creativity and excellent problem solving.


What’s a specific use case of Firebase & Flutter technology that excites you?

Rich: Firebase Extensions are very exciting. They are pre-packaged bundles of code that make it easy to add new features to your app from Google and partners like Stripe and Vonage. We just launched the Extensions Marketplace and opened up the ability for developers to build extensions for their own apps through our Provider Alpha program.

Eric: Flutter web and Firebase hosting is just a no brainer. You can deploy a Flutter app to the web in no time.


How can developers be successful building on Firebase & Flutter?

Rich: There’s a very powerful combination with Crashlytics, Performance Monitoring, A/B Testing and Remote Config. Developers can quickly improve the stability of their apps whilst also iterating on features to deliver the best experience for their users. We’ve had a lot of success with improving monetization, too. Check out some of our case studies for more details.

Eric: Flutter developers can be successful by leveraging all that Firebase offers. Firebase might seem intimidating because it offers so much, but it excels at being easy to use, and I encourage all web and mobile developers to poke around. They’re likely to find something that makes their lives easier.

image of Firebase and Flutter logos against a dot matrix background
What’s next for the Firebase & Flutter Communities? What might the future look like?

Rich: Over the next year we’ll be focusing on modern app development and some more opinionated guides. Better support for Flutter, Kotlin, Jetpack Compose, Swift/SwiftUI and modern web frameworks.

Eric: There is a genuine effort amongst both teams to support each other. Flutter and Firebase are just such a great pair, that it makes sense for us to encourage our communities to check out one another. In the future, I think this will continue. I think you’ll see a lot of Flutter at Firebase events, and vice versa.


How does Firebase & Flutter help expand the impact of developers?

Rich: Firebase has always focused on helping developers get their apps up and running by providing tools to streamline time-consuming tasks. Enabling developers to focus on delivering the best app experiences and the most value to their users.

Eric: Flutter is an app-building SDK that is a joy to use. It seriously increases velocity because it’s cross-platform. Firebase and Flutter offer many tools that “just work”, which is something that all apps need. I think you’d be hard pressed to find another combination of front end framework and back end services that let developers make apps quickly without sacrificing quality.


Find a Google Developer Group hosting a DevFest near you.

Want to learn more about Google Technologies like Firebase & Flutter? Hoping to attend a DevFest or Google Developer Groups (GDG)? Find a GDG hosting a DevFest near you here.

Per-App Language Preferences – Part 1

Posted by Neelansh Sahai Android Developer Relations Engineer (on Twitter and LinkedIn)What if you have a set of users who are quite fluent in English, Hindi, and Spanish, and they have a news app on their phones and prefer to read the news in Hindi? For their texting app, they prefer Spanish as they have some friends and family who they text with in Spanish. But for ease of access, they still prefer their device to be in English. Now there are many such use-cases where the users might want their app languages to be different from their system language. Interesting!

Starting with Android 13, we have included one of the most-requested features from users, Per-App Language Preferences. It lets users switch app languages from System settings, providing users with better control over their language choices for different apps, irrespective of the system language.
A cellphone screen displaying App language preferences in system settings for the YouTube app

Build for your multilingual users

This blog focuses on how to integrate the Per-App Language Preferences API in your app to provide your users the flexibility to choose different languages for different apps.

1.    Users can change the language settings from system settings by selecting: 

Settings → System → Languages & Input → App Languages → [Select the desired App] → [Select the desired Language]

NOTE: Only those apps that have opted in for the feature by specifying the locale_config.xml file (more on this below), will appear in system settings.

A cellphone screen demonstrating finding the language settings from system settings by selecting Settings → System → Languages & Input → App Languages → [Select the desired App] → [Select the desired Language]
2.    If your app already has an in-app language picker, you can integrate the Per-App Language Preferences API to leverage the full platform support. For pre-Android 13 users, the system settings won’t be visible, but developers can still provide an in-app language picker.

A cellphone screen demonstrating integrating the Per-App Language prefences API for an app which already has an in-app language picker

How to integrate this feature in your app?

There are 5 steps that need to be followed while working on the Per-App Language Preferences feature, listed here →

 


1.    Create locale_config.xml file


Create a new file in values/xml/ directory and name it as locale_config.xml. This file should contain a list of all the locales that are supported by the app. The list element should be a string containing a locale tag.

NOTE: The locale tags must follow the BCP47 syntax, which is usually {language subtag}–{script subtag}–{country subtag}. Anything other than that will be filtered out by the system and won't be visible in the system settings.


locale_config.xml

<?xml version="1.0" encoding="utf-8"?>
<locale-config xmlns:android="http://schemas.android.com/apk/res/android">
    ...

    <!-- English -->
    <locale android:name="en"/>



    <!-- Japanese (Japan) -->          
    <locale android:name="ja-JP"/>



    <!-- Chinese (Macao) in Simplified Script -->
    <locale android:name="zh-Hans-MO"/>



    <!-- Chinese (Taiwan) in Traditional Script -->
    <locale android:name="zh-Hant-TW"/>  
    ...
</locale-config>





2.    Add the locale_config in the AndroidManifest.xml

Specify this locale_config.xml file in the app’s AndroidManifest.xml

AndroidManifest.xml

<manifest>
    ...
    <application
        ...
        android:localeConfig="@xml/locale_config">
    </application>
</manifest>


After steps 1 & 2, your users will be able to discover and set their language preference for your app from system settings on devices running Android 13 or higher. In case your users are on devices running on versions lower than Android 13, you can provide an in-app language picker. Optionally, you can also include the same language picker in your app for devices running Android 13 or higher. When your app includes an in-app language picker, it's important for the user's preferences to be in sync between the system and the app. This is where the AndroidX APIs come into the picture. Read on to learn how to create an in-app language picker.




3. Add the libraries

Use the latest version of AppCompat Library

build.gradle (app)

def latestAppCompatVersion =  “1.6.0-rc01”

dependencies {
    ...
    implementation "androidx.appcompat:appcompat:$latestAppCompatVersion"
    implementation "androidx.appcompat:appcompat-resources:$latestAppCompatVersion"
    ...
}




4. Use AndroidX APIs

Use the APIs in your code to set and get the app locales.

MainActivity.kt

val appLocale: LocaleListCompat = LocaleListCompat.forLanguageTags("xx-YY")

// Call this on the main thread as it may require Activity.restart()
AppCompatDelegate.setApplicationLocales(appLocale)


// Call this to get the selected locale and display it in your App
val selectedLocale = AppCompatDelegate.getApplicationLocales()[0]

NOTE: These APIs are also backward compatible, so even if the app is being used on Android 12 or lower, the APIs would still behave the same, and no additional checks for OS versions are required in your code.


 
5. Delegate storage to AndroidX

Let AndroidX handle the locale storage so that the user's preference persists.

AndroidManifest.xml

<application
    ...
    <service
        android:name="androidx.appcompat.app.AppLocalesMetadataHolderService"
        android:enabled="false"
        android:exported="false">
        <meta-data
            android:name="autoStoreLocales"
            android:value="true" />
    </service>
    ...
</application>


Steps 3, 4, & 5 above demonstrate the minimum components needed to create an in-app language picker.

And with this, your app can now support locale switching.


Additional things to take care of while migrating to the API

Earlier, developers had to handle the user's preferences on their own, either by using SharedPreferences, storing the data on a server, or other app logic. With the new APIs, there is no need to handle this separately. So when you are using these APIs, AndroidX is already taking care of the storage part, but what happens when the app is opened for the first time after a user updates their device to Android 13 or higher?

In this case, the system won’t be aware of the user’s preferences for the app language and thus it will map the app to the default system language. To avoid this, developers need to add some one-time migration logic so that their users don’t have to set the language again when they update the app.

// Specify the constants to be used in the below code snippets

companion object {

    // Constants for SharedPreference File
    const val PREFERENCE_NAME = "shared_preference"
    const val PREFERENCE_MODE = Context.MODE_PRIVATE

    // Constants for SharedPreference Keys
    const val FIRST_TIME_MIGRATION = "first_time_migration"
    const val SELECTED_LANGUAGE = "selected_language"

    // Constants for SharedPreference Values
    const val STATUS_DONE = "status_done"
}




// Utility method to put a string in a SharedPreference
private fun putString(key: String, value: String) {
    val editor = getSharedPreferences(PREFERENCE_NAME, PREFERENCE_MODE).edit()
    editor.putString(key, value)
    editor.apply()
}

// Utility method to get a string from a SharedPreference
private fun getString(key: String): String? {
    val preference = getSharedPreferences(PREFERENCE_NAME, PREFERENCE_MODE)
    return preference.getString(key, null)
}


// Check if the migration has already been done or not
if (getString(FIRST_TIME_MIGRATION) != STATUS_DONE) {

   // Fetch the selected language from wherever it was stored. In this case it’s SharedPref

   // In this case let’s assume that it was stored in a key named SELECTED_LANGUAGE
   getString(SELECTED_LANGUAGE)?.let { it →

      // Set this locale using the AndroidX library that will handle the storage itself
      val localeList = LocaleListCompat.forLanguageTags(it)
      AppCompatDelegate.setApplicationLocales(localeList)

      // Set the migration flag to ensure that this is executed only once
      putString(FIRST_TIME_MIGRATION, STATUS_DONE)
   }
}

 

What flexibility does the feature provide to the users and developers?

Here are a few things that might prove to be beneficial for you users.

  1. All devices running Android 13 or higher will have a common place for users to discover and change the language of their apps.
  2. Although the system settings are limited to the devices running Android 13 or higher, the AndroidX APIs are backwards compatible. Thus, there is no requirement to add OS Version checks in your code while building for your multilingual users.
  3. Developers do not need to handle configuration changes separately or worry about storing the user's selected language every time. The API handles configuration changes and stores the language preferences for you.
  4. Works with other Android features like Backup and restore. If a user switches to a new device and restores the previously backed up data, your app will retain the user’s last preferred language, thus providing your users with a better and more seamless experience.

Recap

With that, most parts of the feature are covered. So let’s have a quick recap on what we discussed in today’s read.

  1. A quick read on what Per-App Language Preferences offer to multilingual users and app developers.
  2. What end users will see on their devices.
  3. How to migrate your app to the Per-App Language Preferences APIs.
  4. A few things that need to be taken care of while migrating to the APIs to ensure a better user experience.
  5. Lastly, the benefits that end users and developers can leverage from this feature.

References

  1. Per-App Language Preferences
  2. Sample App ( Compose )
  3. Sample App ( Views )
  4. Per-App Language Preferences (YouTube Video)