Posted by Patrick Fuentes, Developer Relations Engineer, Google ChromeOSPeople’s appetite for apps on larger screens is growing fast. In Q1 2022 alone, there were 270 million active Android users across Chromebooks, tablets, and foldables. So if you want to grow reach, engagement, and loyalty, taking your app beyond mobile will unlock a world of opportunity.
If your app is available in Google Play, there’s a good chance users are already engaging with it on ChromeOS. And if you’re just starting to think about larger screens, tailoring your app to ChromeOS — which runs a full Android framework — is a great place to start. What’s more is that optimizing for ChromeOS is very similar to optimizing for other larger-screen devices, so any work you do for one will scale to the other.
At Android Dev Summit 2022, I shared a few ChromeOS-specific nuances to keep in mind when tailoring your app to larger screens. Let’s explore the top five things devs should consider, as well as workarounds to common challenges.
People freely resize apps on ChromeOS, so it’s important to think about how your app looks and feels in a variety of aspect ratios — including landscape orientations. Although ChromeOS offers automatic windowing compatibility support for made-for-mobile experiences, apps that specifically optimize for larger screens tend to drive more engagement.
The extra screen real estate on Chromebooks, tablets, and foldables gives both you and your users more room to play, explore, and create. So why not make the most of it? You can implement a responsive UI for larger screens with toolkits such as Jetpack Compose and create adaptive experiences by sticking to design best practices.
If you’ve exclusively run your app on Android phones, you might only be familiar with ARM devices. But Chromebooks and many other desktops often use x86 architectures, which makes binary support critical. Although Gradle builds for all non-deprecated ABIs by default, you’ll still need to specifically account for x86 support if your app or one of your libraries includes C++ code.
Thanks to binary translation, many Android apps will run on x86 ChromeOS devices even if a compatible version isn’t available. But this can hinder app performance and hurt battery life, so it’s best to provide x86 support explicitly whenever you can.
The surefire way of ensuring a great user experience? Run rigorous checks to make sure your apps and games work as expected on the devices you’re optimizing for. When you’re building for ChromeOS, testing your apps on Chromebooks or another larger-screen device is ideal. But you've still got options if a physical device isn’t available.
For instance, you can still test a keyboard or mouse on an Android handset by plugging them into the USB-C port. And with the new desktop emulator in Android Studio, you can take your app for a spin in a larger-screen setting and test desktop features such as window resizing.
Sometimes, even apps tested on Chromebooks — and listed in Google Play — aren’t actually available to ChromeOS users. This usually happens because there’s an entry in the app’s manifest declaring it requires features that aren’t available on the unsupported device.
Let’s say you specify your app requires “android.hardware.camera.” That entry refers to a rear-facing camera — so any devices with only a user-facing camera would be considered unsupported. If any camera will work for your app, you can use “android.hardware.camera.any” instead. And if a hardware feature isn’t a must for your app, it’s best to specify in your manifest that it’s not required by using “required=false.”
As people’s love for desktops, tablets, and foldables continues to grow, building for these form factors is becoming more and more important. Check out other talks from Android Dev Summit 2022 as well as resources on ChromeOS.dev and developer.android.com for more inspiration and how-tos as you optimize for larger screens. And don’t forget to sign up for the ChromeOS newsletter to keep up with the latest.
Posted by Neelansh Sahai Android Developer Relations Engineer (on Twitter and LinkedIn)
In part 1 of the Per-App Language Preferences blog, we discussed what the feature is, how developers benefit from it, how to implement the feature, and the strong business impact of catering to multilingual users. In this part of the blog, we'll discuss how various top apps migrated to the Per-App Languages Feature and how it benefited them.
MyJio is the-one-stop destination for recharges, managing accounts & Jio devices, UPI & payments, entertainment services with movies, music, news, games, quizzes & a lot more. With over 500 M+ total installs spread across the globe, MyJio aims to provide its users better access to a variety of utilities. Also as the user-base of MyJio is quite vast, the app supports a total of over 12+ Languages. With these many features and a wide diversity of active multilingual users, MyJio has a strong reason to localize their app using the best practices.MyJio developers implemented the Per App Language Preferences APIs right along with the Android 13 release, allowing their users the flexibility to select a language for their app from system settings as well.
FROM THE DEVELOPERS :At Zomato, providing the best customer experience possible is the core of our business and we believe localization is very critical in giving our customers a pleasant experience on the platform. Our team integrated with the new A13 Per-App Language Preferences API provided by Google to make it easy for our users to switch their preferred language on Zomato.
The ease of integrating the API helped us get it done effortlessly in less than a week’s time. Backward compatibility and stability of the API ensured that we are not compromising on the experience of our customers. With this, we hope to provide a better experience to the customer in their journey of online ordering via Zomato.
FROM THE DEVELOPERS :The demand for using apps in vernacular language is steadily growing in India. After Google announced Per-App Language Preferences recently, it was a straightforward decision to integrate them. The implementation was straightforward, stable, and compatible with older Android versions.
We saw that some top apps have implemented the Per-App Language Preferences APIs in their apps and have also circulated the updates out to the users. This easy migration was possible in such a short timespan due to the low amount of effort investment and minimal code changes required. Lastly, here are some resources that can help you understand the feature better.
Posted by Kseniia Shumelchyk, Android Developer Relations Engineer
Today we’re releasing version 1.1 of Compose for Wear OS, our modern declarative UI toolkit to help developers build beautiful, responsive apps for Wear OS.
Since the first stable release earlier this year, we have seen many developers taking advantage of the powerful tools and intuitive APIs to make building their app simpler and more efficient. Todoist and Outdooractive are some of the developers that rebuilt their Wear apps with Compose and accelerated the delivery of a new, functional user experience.
Todoist increased its growth rate by 50% since rebuilding their app for Wear 3 and Outdooractive reduced development time by 30% and saw a significant boost in developer productivity and better design/developer collaboration:
“Compose makes the UI code more intuitive to write and read, allowing us to prototype faster in the design phase and also collaborate better on the code. What would have taken us days now takes us hours.”
The Compose for Wear OS 1.1 release contains new features and brings improvements to existing components, focusing on UX and accessibility. We’ve already updated our samples, codelab, and Horologist libraries to work with Compose for Wear OS 1.1.
The Compose for Wear OS 1.1 release includes the following new functionality (baseline profiles already added for new components):
A new experimental API has been added to implement placeholder support. This can be used to achieve three distinct visual effects separately or all together:
Check out the reference docs and sample in Horologist to see how to apply the placeholder to common use cases, such as a Chip with icon and a label that puts placeholder over individual content slots and draws a placeholder shimmer on top while waiting for data to load.
Horologist’s fadeAway modifier has been graduated to scrollAway modifier in version 1.1. Modifier.scrollAway scrolls an item vertically in and out of view, based on the scroll state, and already has overloads to work with Column, LazyColumn and ScalingLazyColumn.
CurvedTextStyle now supports additional parameters (fontFamily, fontWeight, fontStyle, fontSynthesis) to specify font details when creating a curved text style. Extended curved text style can be used on both curvedText and basicCurvedText.
The 1.1 release also focuses on bringing a refined user experience, improvements for TalkBack support and overall better accessibility:
To begin developing with Compose for Wear OS, get started with hands-on experience trying our codelab, and make sure to check out the documentation and samples. Visit Compose for Wear OS release notes for full list of changes available in version 1.1.
Note that using version 1.1 of Compose for Wear OS requires using the version 1.3 of androidx.compose libraries and therefore Kotlin 1.7.10. Check out the Compose to Kotlin Compatibility Map for more information.
Compose for Wear OS continues to evolve with the features you’ve been asking for. Please do continue providing us feedback on the issue tracker and join Kotlin Slack #compose-wear channel to connect with the Google team and dev community.
We’re excited to see a growing number of apps using Compose for Wear OS in production, and we’re grateful for all issues and requests that help us to make the toolkit better!
Discover even more with technical sessions from the Android Dev Summit providing guidance on app architecture, testing, handling rotary input, and verticalized sessions for media and fitness.
Posted by Wolfram Klein, Product Manager, Android TV OSToday we’re releasing the newest version of Android TV OS, Android 13 for TV! This latest release brings further improvements in performance and accessibility to help our developers build engaging apps for the next generation of TVs.
Here’s a look at some of what’s new in Android 13 for TV.
Android 13 brings new APIs to the big screen that help developers deliver high quality experiences to users across different device types.
Android 13 brings new features to make interacting with TV more adaptable.
Check out the Android TV OS developer site for details on even more features that come with Android 13 on TVs. The new release is now available for both ADT-3 and the Android TV emulator, and developers can choose to test on either the Google TV interface or the standard Android TV interface. As always, we are thankful to our developers for the continued support of Android TV OS. We can’t wait to see what amazing and innovative experiences you’ll continue to build for the big screen.
Posted by Aditya Swamy, Director, Google Play PartnershipsI sat down for a “virtual coffee” with Haemin Yim, founder and CEO of Creatrip, from Korea to discuss starting on the web, setting up the company for global reach, and tips for startups looking to grow.
Despite having a great idea for an app, Haemin shared with me that it hasn’t always been smooth sailing. After gaining significant brand awareness and with increasing travel bookings across the app, the pandemic sent the travel industry into disarray. As with many businesses, this had significant implications for Creatrip. However, Haemin and the team used their strong understanding of the people using their app to quickly expand their offering.
With the knowledge that people often wanted to visit South Korea because of their interest in K-trends and culture; Haemin adapted the business to provide K-products to those who were unfortunately unable to travel during that period. This led Haemin to grow the business beyond just a travel app and into a global e-commerce platform.
Creatrip started as an app that provided travel content. It quickly expanded to provide people with in-app booking features, local currency exchange rates that weren’t previously digitized, and even a global e-commerce platform providing access to popular ‘K-items’. However, content is the key element that draws users into the app.
My top advice for businesses looking to continue to evolve their content is to expand their content creator pipeline. For example, by encouraging South Korean locals to contribute, Creatrip could gain a richer and more diverse range of content, showcasing Korea through the eyes of many different people. Haemin and the team are already in the process of building a new feature that allows people to create their own content on the app.
Think about short form video apps. By allowing people to become their own content creators, it enables them to have a much wider repository of content and encourages users to spend more time on the app. Now more people want to be creators and make their own content as seen on YouTube. This is fueling growth in watchtime, and adding more users.
Something I found particularly interesting from my chat with Haemin, was how she prepared the business for global reach from the start. Haemin believes that despite requiring a bit more time and effort, preparing for global reach from the beginning can actually allow for exponential growth, as you start to target the right markets and reach a global fan base. It is wonderful to see how Haemin brings her passion for all things Korean, to people all around the world. The team’s first step towards going global was by listening to and understanding the needs of the people already using Creatrip.
The team at Creatrip have definitely brought a lot of unique ideas to the app. With 90% of their users having started on the website, the team had an ingenious idea to bring people over to mobile. They listened to their global users and saw that people were keen to find out the currency exchange rates being provided at local stores in Seoul. They created a mobile-only feature that shows local currency rates from local stores. This required the team to actually go to the stores twice a day, however it led to a large increase in people using the mobile app - all by providing information that was previously unavailable to people from outside of Seoul.
It’s amazing to see how much Creatrip is flourishing; the app has grown from 100k monthly users up to 1.5 million. There are many factors that helped Creatrip grow over the past few years, but some notable takeaways from my chat with Haemin include:
As a final thought I couldn't let Haemin go without asking her favorite K trends. She mentioned that fusion fine dining was a top trend in Korea, NewJeans were a trending K-pop band, and South Korean blankets were a top K-product.
Do you have any questions for Creatrip? What are your own tips for other app or game businesses? Let us know on Twitter.
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!
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.
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
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.
<?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>
<manifest> ... <application ... android:localeConfig="@xml/locale_config"> </application></manifest>
def latestAppCompatVersion = “1.6.0-rc01”
dependencies { ... implementation "androidx.appcompat:appcompat:$latestAppCompatVersion" implementation "androidx.appcompat:appcompat-resources:$latestAppCompatVersion" ...}
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 Appval 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.
<application ... <service android:name="androidx.appcompat.app.AppLocalesMetadataHolderService" android:enabled="false" android:exported="false"> <meta-data android:name="autoStoreLocales" android:value="true" /> </service> ...</application>
// 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 SharedPreferenceprivate 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 SharedPreferenceprivate 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 notif (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) }}
Here are a few things that might prove to be beneficial for you users.
With that, most parts of the feature are covered. So let’s have a quick recap on what we discussed in today’s read.
Platform
Android Studio
Google Play
Jetpack
Kotlin
Docs
News
![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]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEigMMkDrk24GFhwQYTFL3SOe7BtcvUXhnudcyYkJE4um0woEr2aRZ78LqcP8_UaqoSJliwQmoBllEw44RwSYuPTaG372Oyorri8Q_qkaapDOrzkU6nR_kWh9pQTx6Jj6Tqmjb4VwqiPtn43bZsOoAQyQ1RZ9kLnhbEScICv-ApjTaPNS7Gd3L4HxJZu/s1600/image1.gif)
