This page describes the window manager on Chrome OS.
The window manager on Chrome OS
Android apps are grouped into the following categories:
API level | Window manager behavior |
---|---|
Android 1.5 (API level 3) and earlier | These apps are always shown full screen. |
Android 1.6 (API level 6) through Android 6.0 (API level 23) | These apps are treated as unsafe to be resized. If possible, these apps launch by default to a phone-sized portrait window; otherwise they launch into a phone-sized landscape window. The user can press F4 to enter or leave full screen mode which fully restarts the app—killing and starting the app anew—and keeps it from then on in full screen portrait-sized (or rotated into landscape). |
Android 7.0 (API level 24) resizable | This is the default for Android 7.0: apps are resizable without restarting. These apps start usually maximized by default. Chromebooks at version M60 and earlier start portrait sized windows by default in phone sized (Nexus 5X) portrait. |
Android 7.0 (API level 24) un-resizable |
An application specifies
android:resizeableActivity="false" and it avoids being
resized. However, there are some situations that require a resize, such
as when the user changes the screen size, the activity is on top of a
resizable activity, or the activity changes the orientation.
|
Android 7.0 (API level 24) app-controlled | The app requests a special launch size. |
Note that app states like maximized or bound are remembered.
The root activity rules
A window on Chromebooks consists of a stack of activity windows. Each window in this stack has the same size and orientation.
To avoid sudden orientation and size changes—which are confusing for the user in a desktop environment—the window manager on Chromebooks does the same as the window manager in Android when the side by side mode is used:
- The activity at the bottom of the stack dictates the attributes of all activities above. This can lead into unexpected situations where a newly started activity which is portrait unresizable becomes landscape resizable.
Device mode has an effect here: in tablet mode the orientation is not locked and each orientation dictates its own orientation as it is normal on Android. However, the app size locks, if the activity targets Android 6.0 (API level 23) or lower.
Orientation
The most common orientation is portrait as phones are mostly held this way. This mode is good for phones, but terrible for laptops. On the other hand, landscape is good for laptops and good for tablets. To get the best results for your application with a window manager, you should consider supporting both orientations.
Some Android apps assume that when a device is
held in the portrait mode, the rotation value is always
Surface.ROTATION_0
. This may be true for
most Android devices. However, when the app is in a certain
ARC
mode, the rotation value for the portrait orientation may not be
Surface.ROTATION_0
.
To get an accurate rotation value while reading the accelerometer or similar
sensors, use the Display.getRotation()
method and swap the axis accordingly. For more information on setting the
orientation, download the
AccelerometerPlay
sample app.
If you support only one, add the information to the manifest so that the window manager knows about this before starting the application. When specifying an orientation, make sure that you specify sensor orientations when possible as Chromebooks are often convertibles and upside down apps are annoying. Please do stick with a selected orientation - and most important of all: Avoid requesting one orientation in the manifest and then set another programmatically later. If you change the orientation based on window size, you might get stuck in a small portrait size window, and the user cannot get back into a big landscape window.
Launch size
Apps can change their launch size by using one of the following ways:
Use a launch size only in desktop environments. This helps the window manager to give you the proper bounds and orientation. To indicate a preferences when used in desktop mode, add the following meta tags inside the
<application>
tag:<meta-data android:name="WindowManagerPreference:FreeformWindowSize" android:value="[phone|tablet|maximize]" /> <meta-data android:name="WindowManagerPreference:FreeformWindowOrientation" android:value="[portrait|landscape]" />
Use static launch bounds. Use
<layout>
inside the manifest entry of your activity to specify a "fixed" starting size. See this example:<layout android:defaultHeight="500dp" android:defaultWidth="600dp" android:gravity="top|end" android:minHeight="450dp" android:minWidth="300dp" />
Use dynamic launch bounds. An activity can create and use
ActivityOptions.setLaunchBounds(Rect)
when creating a new activity. By specifying an empty rectangle, your app can be maximized.
Full screen
This works the same way as on stock Android: If the window is not covering the full screen, requests for full screening (hiding all system-UI) are ignored. When the app is maximized the normal methods / layouts / functions to get into fullscreen mode apply. This way the system UI (window control bar and the shelf) goes away.