ChromeOS lint rules in Android Studio

We, at ChromeOS, are committed to enhancing developer tools and frameworks that enable Android app developers to optimize their apps for Chromebooks seamlessly. In doing so, we need to look consistently at ways to bring impactful tool sets to developers to enhance the experience of building for large screens and ChromeOS.

ChromeOS has evolved through the years as new challenges have presented themselves. One of these challenges is identifying critical issues to engineers early and often. Lint rules are at the heart of quality, as they provide flare signals to developers for issues that will arise if not remedied. Our updated lint rules provide developers with more visibility into how their apps run on ChromeOS, showcasing issues, both software and hardware, that will undoubtedly cause issues for Android applications that are run on any ChromeOS device.

To get more background context on the existence of these lint rules and their importance, read through our blog post.

Where are these lint rules?

We have been in active development for a few months now. With the release schedule of Android Studio, some lint rules are being introduced with the Electric Eel Canary builds. A few of these lint rules are also now available in the Flamingo Canary releases. We will continue to build towards having these in the stable versions of Android Studio in the coming months.

Another major thing to note is that these rules will be enabled by default in newer versions of Android Studio. The goal of this is to have more strongly opinionated guidance on how we want to help engineers build for ChromeOS and larger screens going forward.

New lint rules (updated as of Flamingo Canary 3)

x86/x86_64 ABI support

The majority of Chromebooks run on the Intel architecture, thus making them a predominantly x86 architectural platform. For ChromeOS to properly be supported when NDK code is included as part of the binary, having x86 is a performance boost due to removing the translation required from ARM libraries. Therefore, it is strongly recommended that your development team adds x86 or preferably x86_64 architecture support as it would be a performance boon for any native code on ChromeOS or any Intel device.

Remedy

If possible, add x86 and x86_64 inside of your abiSplits within your build.gradle. Also, ensure that you are adding the code to the appropriate folders to support these ABIs. To get more information, reference the documentation on Android ABIs⁠⁠ and the talk on ABI Support from ADS⁠⁠.

ChromeOS hardware limitation

The majority of ChromeOS devices come with a smaller sample set of hardware sensors and other features compared to an Android phone. The goal of this rule is to flag to developers that if you are using the flag <uses-feature> with android:required=true, your app will not be available on the Google Play Store on ChromeOS. A strong recommendation to ensure that your app can be accessed on as many devices as possible is to ensure that the hardware feature is not required by default. Instead, you can add defensive code to check for specific hardware at run time rather. An example of this would be

%lt;uses-feature android:name="android.hardware.camera" android:required="true"%gt;

Remedy

Ensure that the features that are within your application are actually required, and if they are not, change the android:required parameter to false and add defensive programming when API calls are required. To get more information, reference the documentation on explicitly declared features.⁠⁠

Non-resizable activities

By default, Android Runtime for ChromeOS, running Android R or higher on Chromebooks, starts an Android app in either the phone or tablet version of the application, based on the default UI state. However, there is a third option that is a better experience for ChromeOS users, the Resizable mode. By enabling this flag as part of your Activity, users that can use your application in any multi-window environments can take advantage of resizing your application to the appropriate size. These changes will allow users to scale the UI to meet their needs. After adding these changes to your Manifest, test your application against the Desktop Emulator referenced below.

Remedy

Add the resizableActivity="true" attribute to your Activity in your AndroidManifest.xml file. To get more information, reference the documentation on large screen restrictions⁠⁠.

Configuration changes

One major caveat to resizable screens is that every time a user changes the size of the application, onConfigurationChanged() is called. If your app is issuing a full redraw inside of that method, there will be performance implications associated with it. Currently, we are checking to ensure that finish() is not called within onConfigurationChanged, as you should be handling the savedInstanceState with more granularity versus enforcing a full redraw. We will continue to find cases where performance degradation will occur and update this rule accordingly.

Remedy

Ensure that finish() is not called within the onConfigurationChanged() API in your Activities and Fragments. To get more information, reference the documentation on handling configuration changes⁠⁠.

Keyboard and mouse support

With the increased adoption of Jetpack Compose, we wanted to ensure that building with those libraries also included functionality for mouse and keyboard support going forward. Over time, we will continue to increase the usability of mouse, keyboard, trackpad, and other peripheral interactions. In order to get the baseline experiences, you’ll have to update your Gradle dependencies to the minimum required versions.

Remedy

Update androidx.compose.foundation:foundation to a minimum version of 1.2. To get more information, reference the compose version release notes⁠⁠.

Feedback

The team is constantly looking to improve these tools and documentation surrounding optimizations for large screens. A critical step in this process is to give us feedback on the accuracy and usefulness of the lint rules that are deployed in Android Studio. You can do this by providing feedback for the rule. When the lint rule shows up in Android Studio, click on “Provide feedback on this warning”. You should be taken to a dialog that looks similar to the one below. The more accurate and descriptive the information given, the more we are able to iterate quickly on making the appropriate changes.