Skip to content

Most visited

Recently visited

navigation

Input compatibility for Chromebooks

Users on laptops often use different input devices than on phones.

Running on Chromebooks, Android apps find themselves in an environment they were not designed for, displayed inside a window on a laptop with mouse, touchpad and keyboard. While Android does have support for those devices, they are rarely properly implemented in apps. In order to make these apps work, Chromebooks use a compatibility mode that is applied to all apps by default.

Compatibility mode

In compatibility mode, your app will receive events differently from how they are provided by Android APIs. This mode is useful for developers that do not want to implement Chromebook-specific features, but want their touch-centric app to just work.

The compatibility mode introduces the following behaviors:

Depending on the API level your app is targeting, compatibility mode provides more or less of these compatibility treatments.

Use android.hardware.type.pc

If you want to optimize your app for running on Chromebooks and to make good use of the input devices, declare the following in your app manifest:

<uses-feature
    android:name="android.hardware.type.pc"
    android:required="false" />

This tells Android that you are targeting PC devices that are typically used with keyboard, mouse, and touchpad. It disables the compatibility mode and allows you to develop custom behavior for mouse and touchpad.

Beware the DecorCaptionView

In free-form window mode, the apps caption bar is part of your view hierarchy and under your control. You generally do not have to be aware of this, but there are cases where you have to be careful:

Input device support

Once you are targeting PC devices via the android.hardware.type.pc flag, you can expect the following events:

Mouse and Touchpad

Mouse and touchpad both generate MotionEvents just like touch events. Check MotionEvent.getSource() to distinguish SOURCE_MOUSE, SOURCE_TOUCHPAD and SOURCE_TOUCHSCREEN.

Keyboard

Keyboard input is important on desktop and laptop devices. It is also highly required for accessibility.

To get proper input focus activation, you should follow the normal resource additions as outlined in the default Android API:

Stylus

A stylus reports events similar to a touchscreen via View.onTouchEvent(). However, stylus events carry more information that should be accounted for:

Historical Points

Android batches input events to be delivered once per frame. A stylus pen, however, can report at much higher frequencies (200Hz being quite common). When creating drawing apps, it is important to use of points acquired from the historical API:

Palm Rejection

Chrome OS attempts to recognize resting palms so they are never reported to the app. However this is not always possible: sometimes a touch may be reported before the OS recognizes it as a palm. In that case, touches will be cancelled by reporting an ACTION_CANCEL event.

This event tells the app that all touches are invalid and it should undo all interactions caused by the touches. For example, in case of drawing apps, the app will temporarily draw new lines and commit them to the canvas only once the touch series is finished cleanly. If the touch is cancelled, that temporary line can be easily removed.

Note-Taking Intent

Chrome OS displays a list of apps that are registered to handle intents containing an org.chromium.arc.intent.action.CREATE_NOTE action and the Intent.CATEGORY_DEFAULT (i.e. android.intent.category.DEFAULT) category as shown in the following code snippet:

  <intent-filter>
    <action android:name="org.chromium.arc.intent.action.CREATE_NOTE" />
    <category android:name="android.intent.category.DEFAULT" />
  </intent-filter>

The user will be able to select an app, and that app will later be launched when a note-taking app is requested.

When the user requests creating a new note, the app will be launched using an intent containing just the aforementioned action and category. The app should create an empty note in a mode where the user can write using a stylus.

When the user requests annotating an image (e.g. a screenshot or downloaded image) context, the app launches using an intent with the aforementioned action and category, including ClipData containing one or more items with content:// URIs. The app should create a note that uses the first attached image as a background image in a mode where the user can draw on it using a stylus.

Testing without a stylus

  1. Switch to dev mode and make the device writable.
  2. Press Ctrl+Alt+F2 (forward-arrow) to open the shell.
  3. Run the command sudo vi /etc/chrome_dev.conf.
  4. Add --ash-enable-palette to a new line at the end of the file.
  5. Press Ctrl+Alt+F1 (back-arrow) to return to the UI.
  6. Log out and back in.

You will now see the stylus entry points: - In the shelf, you can tap the stylus button and choose “New note”. This should open a blank drawing note in your application. - If you take a screenshot (from shelf: stylus button > Capture screen) or download an image, you should see the option “Annotate image” in the notification. This should open your app with the image ready to be annotated.

Gamepads

Chromebooks support up to 4 gamepads and follows standard Android APIs for reporting them. Unfortunately it is quite common that gamepads not designed for Android show the right button mapping.

This site uses cookies to store your preferences for site-specific language and display options.

Get the latest Android developer news and tips that will help you find success on Google Play.

* Required Fields

Hooray!

Browse this site in ?

You requested a page in , but your language preference for this site is .

Would you like to change your language preference and browse this site in ? If you want to change your language preference later, use the language menu at the bottom of each page.

This class requires API level or higher

This doc is hidden because your selected API level for the documentation is . You can change the documentation API level with the selector above the left navigation.

For more information about specifying the API level your app requires, read Supporting Different Platform Versions.

Take a one-minute survey?
Help us improve Android tools and documentation.