How how can we keep Overlay Surface unchanged when switch from Portrait to Landscape mode

by tony » Wed, 29 Apr 2009 08:26:55 GMT


Sponsored Links
 In current android implementation,all the Surface will rotate 90degree
when switch to landscape.

We have requirement to keep the video unchanged (no rotation) and it
seems the only way is to ignore the orientation in
LayerBuffer::OverlaySource::onVisibilityResolved().

Please let me know if you have comments.
--~--~---------~--~----~------------~-------~--~----~



How how can we keep Overlay Surface unchanged when switch from Portrait to Landscape mode

by Dave Sparks » Wed, 29 Apr 2009 17:31:08 GMT


 The application chooses the orientation. You can't force this from the
hardware layer.



--~--~---------~--~----~------------~-------~--~----~


Sponsored Links


How how can we keep Overlay Surface unchanged when switch from Portrait to Landscape mode

by Feike » Thu, 30 Apr 2009 05:19:05 GMT


 I met this issue too, I suggest google should add a new attribute
NO_ROTATION in frameworks/base/core/java/android/view/Surface.java,
then check it in LayerBase.cpp::validateVisibility(...) function to
decide if re-calculate the orientation and position for this layer
(surface). So it will provide a capability for user to control each
surface's rotation.

For example:
Camera application's controller surface need rotate according to the
phone status(landscape or portrait), but its viewfinder surface
needn't rotate.
In current android platform, we can correct it in
LayerBuffer::OverlaySource::onVisibilityResolved(), but it will
prevent all surfaces that use overlay to rotate, it isn't good method.




--~--~---------~--~----~------------~-------~--~----~



How how can we keep Overlay Surface unchanged when switch from Portrait to Landscape mode

by tony » Thu, 30 Apr 2009 10:00:13 GMT


 Agree with feike, it's better to add interface in java class Surface
to control if  orientation is allowed. I believe many use case need
such API especially for Push Surface.
--~--~---------~--~----~------------~-------~--~----~



Other Threads

1. API Call Management: Issues 54 and 675

Hi folks,
 Has any one gotten an API solution to reject and/or terminate calls as 
described in issues #54 and 675? Both of these items have been reviewed 
and accepted, but it doesn't appear that an engineer has been assigned 
to either one.

http://code.google.com/p/android/issues/detail?id=54
http://code.google.com/p/android/issues/detail?id=675

 I suppose there might be security issues posed by these, after all a 
malicious application could then intercept calls and hold a phone 
hostage, but there are legitimate reasons for providing this 
functionality as well. Any comments from the Google folks?

Thanks,
Raymond

--~--~---------~--~----~------------~-------~--~----~

2. I2C Devices

I am trying to write a driver for a I2C chip. I did insmod on my
driver from android shell, I can see the printk in the "init" getting
executed.

To my understanding...
What init does is, it calls i2c_add_driver(xxxxx); to register my
driver with i2c core.

Upon registration i2c core should find a i2c adapter, if it finds
adapter, it should invoke attach function that was part of the
i2c_driver struct.

attach function should look for the device(address) on the i2c but via
I2c Adapter, it finds a device at the address that its looking for, it
should then invoke the probe and let the fun begin...

But I dont see a printk inside my attach function getting executed,
which prompts to suspect that kernel is not detecting any "simulated"
i2c adapter...

Can you please comment.

--~--~---------~--~----~------------~-------~--~----~

3. Send SMS from one emulator instance to another

4. StackOverflowError when clearing and refocusing a ghosted text view

5. Story about Android

6. Dynamic UI forms

7. I'd like to modify the Dialer program