Initial Screen Orientation

[prunand]

I am working on a device that is designed to be run in landscape
mode. The display used is configured as portrait, however. The
device has no G-Sensor to detect its orientation.

I have modified PhoneWindowManager.rotationForOrientationLw() to
return landscape based on an env variable. This works fine after the
device has fully completed booting. The problem is the lock screen
initially shows in portrait mode for a second or two before it flips
to landscape. I would like to have it show up in landscape mode
initially.

At this point, I think I need to change SurfaceFlinger to honor the
env variable, and set the initial orientation accordingly. Does this
sound right? If so, is there a certain part of SurfaceFlinger I
should look at first?

[Dianne Hackborn]

If your device is running in landscape, its native orientation should be landscape, and you shouldn't have to do anything to change it to use that.  Certainly, at least if you are working with 2.2, don't modify rotationForOrientationLw() to just arbitrarily "make" this work, since you could very easily break behavior applications expect.

Android will run in the device's native orientation (that is, not applying a rotation to what is displayed on the screen) unless something tells it not to.  If there is no accelerometer, this will not impact the rotation (though do check that there isn't a problem here because the current code generally assumes an accelerometer so I'm not sure what will happen without one).  Individual windows and activities can request an orientation.  Very little in the platform should force a particular orientation, though both the lock screen and the launcher tell the window manager to ignore the sensors for determining orientation.

--
unsubscribe: android-porti...@googlegroups.com
website: http://groups.google.com/group/android-porting

--
Dianne Hackborn
Android framework engineer
hac...@android.com

Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails.  All such questions should be posted on public forums, where I and others can see and answer them.

[Andrew Prunicki]

I guess I missed a couple of details in my first note. The device is
intended to be used in landscape, but due to an unfortunate mfg
glitch, the display used is apparently made for portrait use. Hence,
the display hardware and driver reports portrait as its native
resolution. We are using 2.0.1 for this device.

By breaking behavior that applications expect when changing
rotationForOrientationLw(), I assume you mean that an application will
expect to be in portrait, but get landscape instead? The apps I have
tested support both orientations. I'll try it with a fixed portrait
app to see how it works with that app. The way buttons are laid out
on the device, portrait-only apps won't work well anyway. Is there
some other expected behavior that I may be breaking by pursuing this
approach?

If I want to instruct Android to change the orientation to landscape
up-front, is SurfaceFlinger the place to go, or would modifying the
display driver itself be a better approach?

> > unsubscribe: android-porti...@googlegroups.com<android-porting%2Bunsu...@googlegroups.com>

> > website:http://groups.google.com/group/android-porting
>
> --
> Dianne Hackborn
> Android framework engineer

> hack...@android.com

[Dianne Hackborn]

On Thu, Nov 18, 2010 at 7:46 AM, Andrew Prunicki <andrew....@gmail.com> wrote:

I guess I missed a couple of details in my first note.  The device is
intended to be used in landscape, but due to an unfortunate mfg
glitch, the display used is apparently made for portrait use.  Hence,
the display hardware and driver reports portrait as its native
resolution.  We are using 2.0.1 for this device.

Then you'll need to do some hacks.  (See below.)

 

By breaking behavior that applications expect when changing
rotationForOrientationLw(), I assume you mean that an application will
expect to be in portrait, but get landscape instead?  The apps I have
tested support both orientations.  I'll try it with a fixed portrait
app to see how it works with that app.  The way buttons are laid out
on the device, portrait-only apps won't work well anyway.  Is there
some other expected behavior that I may be breaking by pursuing this
approach?

To be a compatible device, you *must* respect the requests of apps for the orientation they are to run in.  If you don't care about being a compatible device, then it is up to you what you want to do.

 

If I want to instruct Android to change the orientation to landscape
up-front, is SurfaceFlinger the place to go, or would modifying the
display driver itself be a better approach?

You can modify rotationForOrientationLw() so that the mPortraitRotation and mLandscapeRotation provide the appropriate rotation to achieve those two orientations on your device:

http://android.git.kernel.org/?p=platform/frameworks/policies/base.git;a=blob;f=phone/com/android/internal/policy/impl/PhoneWindowManager.java;h=dec495d1b0dc368da5728017e70135f19f90f1c0;hb=HEAD#l2111

You may also need to modify other rotations like mCarDockRotation if appropriate.

--
Dianne Hackborn
Android framework engineer

hac...@android.com

[Dianne Hackborn]

(Note you may not need to modify mCarDockRotation -- its default rotation is to rotate based on the sensor, for example.)