Screen size compatibility for Chromebooks

The implementation of Android apps on Chrome OS includes basic multi-window
support. Instead of automatically drawing over the full screen, Android
renders apps on Chrome OS into layouts that are appropriate for the form
factor.

Resize tasks and windows

Because the activity's window size can change, activities should read the
activities' resolution upon start. Activities should react to resolution
changes by calling onConfigurationChanged(..). For example,
to avoid losing user's work upon maximization, you can do either of the
following:

Restore the previous state by using onSaveInstanceState to
make the transition as simple as possible. This is applicable where
requesting a restart is the only option.

When looking for the current configuration, always use the configuration
from your current activity in getResources().getConfiguration().
Do not use the configuration from your background activity or the one from the
system resource. The background activity does not have a size, and the
system's configuration may contain multiple windows with conflicting sizes and
orientations, so no usable data can be extracted.

Another important consideration is that window content bounds can change.
For example, the area within the window that is used by the app can
change if the window gets too big to fit the screen. Consider the following
guidelines:

Apps that utilize Android's layout process should automatically
be laid out in the available space.

Native apps should read the available area and monitor size
changes to avoid having inaccessible UI elements. Call the following
methods to determine the initial available size for this surface:

NativeActivity.mLastContent[X/Y/Width/Height]()

findViewById(android.R.id.content).get[Width/Height]()

Continuous monitoring can be done via observer:

NativeActivity.onContentRectChangedNative()

NativeActivity.onGlobalLayout()

Add a listener to
view.addOnLayoutChangeListener(findViewById(android.R.id.content))

If the app is pre-scaling its artwork, it should do this every
time the resolution changes.

The system supports free resizing; however, not all apps were written with
resizing in mind. Here are some potential issues to look for:

Handle resizing seamlessly. You can get resized at any point in time
because of all kind of reasons. As such it is really important to be
able to save and restore your state as well as possible via
onSaveInstanceState if a restart becomes necessary.
Note that this is also beneficial for Android in general.

Also make sure that an activity restart is fast by caching objects
you have previously allocated. If you do not use the frameworks layout
mechanisms—so your app would for example use OpenGL and
scale the content, or some other logic kicks in—you should listen to
onConfigurationChanged events to avoid activity restarting.
Make sure to specify all change events you can handle dynamically.

If you do not want to get resized you should specify this in your
manifest file accordingly.

It is important to note that the window size is not the screen size and
that you probably never need the screen size anyways.
To get the window size you should use
Activity.getResources().getConfiguration().screenWidth
and Activity.getResources().getConfiguration().screenHeight
in DP.

To get your current configuration, always use your activity's resource and
get the configuration from there, since otherwise you might end up looking at
"something," such as the screen properties.

Note that the screen position can change as well. So be sure to always use
the system to do window-to-screen space calculations or vice versa.

If you are using Android's view system, your window should get layed out
automatically with a size change.

If you do not use the view system and take over the surface, your app must
handle size changes on your own.

Native apps should use the mLastContent members—or
getting the content view to get the initial size.

Once the app is running it should listen to
onContentRectChangedNative or
onGlobalLayout events to react to size changes.

Note that with a size change an app should rescale or reload layouts,
artwork and update input areas.

Layout

To fill the screen with more information, you can specify different
layouts, or you could create the layout dynamically for the requested
size. Note that dynamic generation is generally not recommended, but
might sometimes be a possibility.

Apps that do not use the layout system should avoid restarting
for a configuration change as they might be really expensive. These changes
can happen because of obvious reasons like window size changes, but also for
non obvious ones—like a device mode conversion. Changing from laptop into
tablet would for example report a change that the physical keyboard went
away. A restart which makes the user wait or even lose work unexpectedly is
not a good experience.

Make sure that your code does not try to access UI elements that have gone
away due to a dynamic resize operation.

Monitor view hierarchy changes

Adding a window control caption can cause some problems. Consider the
following recommendations:

Don't expect your content to start at (0,0) of the window. The window
content might be offset by the height of the caption. Look at the
view's screen location using View.getLocationInWindow() to
get the correct offset.

Don't expect that the DecorView is the holder of the
contentView. The caption is part of the window hierarchy and
if it exists, it is located between the DecorView and the
content view. As such, adhere to the following:

Don't change the view hierarchy directly below
DecorView.

Don't assume that the child from DecorView is of type
LinearLayout.

Don’t make the assumption that Configuration.screenHeightDp
is the height of your app’s content area. Part of this height is
taken up by the caption view, if one exists. The same applies to
Display.getSize(), and so on.

Other considerations

Here are some other aspects to consider:

If your activity is always intended to run in full screen, add the
android:resizeableActivity="false" flag to your
manifest.

End users are presented with window controls to toggle among all
available layouts. By choosing the correct orientation option, you can
ensure that the user has the correct layout upon launching the app. If
an app is available in portrait and landscape, it defaults to landscape,
if possible. After this option is set, it is remembered on a per-app
basis.

Try to avoid unnecessary orientation changes. For example, if the
activity orientation is PORTRAIT, but the app calls
setRequestedOrientation(LANDSCAPE) at runtime, this
causes unnecessary window resizing, which is annoying to the user and
possibly restarts if your app cannot handle it. The preferred option is
to set the orientation once, for example, in the manifest, and only
change it if necessary.

Don’t call finish() in your activity’s
onDestroy method. This causes the app to close upon resize
and not restart, assuming your app has to restart.

Don’t use window types that aren't compatible, such as
TYPE_KEYGUARD and TYPE_APPLICATION_MEDIA.

Note: We recommend that you test your
app to ensure that it handles changes in window size appropriately.