1 / 29

Dual Display for Android Applications

Dual Display for Android Applications. Gururaj N 21st Jan, 2011 v0.2. Agenda. Introducing Teleca History of Multi Display Dual Display Mobile Devices Teleca’s experience in Dual Display for Android Devices QA. Introducing Teleca.

parley
Download Presentation

Dual Display for Android Applications

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Dual Display for Android Applications • Gururaj N • 21st Jan, 2011v0.2

  2. Agenda Introducing Teleca History of Multi Display Dual Display Mobile Devices Teleca’s experience in Dual Display for Android Devices QA

  3. Introducing Teleca Teleca is the only player in segment with comprehensive onshore/offshore global delivery footprint across all major markets Wehave 2000 mobile softwareengineersavailableworldwide

  4. Agenda Introducing Teleca History of Multi Display Dual Display Mobile Devices Teleca’s experience in Dual Display for Android Devices QA

  5. History of Multi-Monitor (1) – PC and TV Dual Monitors at Work Place Picture in Picture • Multi monitor use case • Engineer needs as bigger screen possible to enhance productivity • HW Support – two video ports, or add second video card • OS Support – Adjust display properties • PIP use case • Two programs side–by–side and audio output of one program going into speaker and another going to headset • Two tuner built into TV set OR one tuner being external source like DVD player.

  6. History of Multi-Monitor (2) – Mobile Phones • Multi display Mobile Phone usecases • The secondary display is used typically for notifications ( messages, incoming call ) and Clock • HW Support – two display drivers • OS Support – Adjust display properties • Separate applications running on two screen • Disadvantages • Cannot write applications for secondary display • Only one display is active at any time. • Low resolutions

  7. Agenda Introducing Teleca History of Multi Display Dual Display Mobile Devices Teleca’s experience in Dual Display for Android Devices QA

  8. Dual Display Mobile Devices (1) Samsung Continuum Acer Iconia • Acer Iconia • Concept laptop. • Used as e-Reader • One of the display can become Soft-Keyboard. • Samsung Continuum Use cases • Dedicated Ticker Display for displaying Music player controls, RSS feeds, Social network site updates, Incoming call notification. • The idea seems to be use the second display for dynamically changing data without affecting the activities user does on main screen

  9. Dual Display Mobile Devices (2) • HW Support • Two different displays • Two different frame buffers and drivers • One display virtually split into two displays • Single virtual frame buffer to support two independent displays • SW Support • Framework changes to support dual displays • SDK changes to program applications specific to Dual display • Currently not available, mostly proprietary

  10. Agenda Introducing Teleca History of Multi Display Dual Display Mobile Devices Teleca’s experience in Dual Display for Android Devices QA

  11. Teleca’s experience in Dual Display for Android (1) Teleca Worked on all aspects of Dual Display on Android

  12. Teleca’s experience in Dual Display for Android (2) • Teleca built Dual Display for Android with Texas Instruments • Demonstrated at MWC 2009 • Development Environment • TI Zoom3(OMAP 4430) with Dual Display Support (each display 864x480) • Android 2.0 ( Éclair )

  13. Teleca’s experience in Dual Display for Android (3)- Components • Android Components involved in Dual Display • Applications - need to define onto which display their Activities should go. • Activity Manager – launch application’s activities onto the right display. • Window Manager – needs to properly handle two Activity stacks and two window stacks • Surface Flinger – needs to handle layer composition for two displays. • OpenGL / EGL – needs to support one context for each display • Linux Kernel / Driver – support for two secondary display for output and touch input

  14. Teleca’s experience in Dual Display for Android (4)- Design Approaches for Window Manager Support Pros Cons • Interface to only one Window Manager • No additional thread • Very complex 11K lines of code • Massive design changes to central Android component • Single Window Manager concept • This concept is based on an extension of the existing Window Manager for the second display. The WindowManagerService would be extended to support a second stack of activities and a second stack of windows. • The Activity Manager would –based- on the applications preference or the preference of an Activity create the Activity on the right stack of the Window Manager. Besides the changes to the ActivityManager the main changes need to be done in the WindowManagerService and the IWindowManager.aidl.

  15. Teleca’s experience in Dual Display for Android (5)- Design Approaches for Window Manager Support • Second Window Manager • The concept proposes to duplicate the WindowManagerService code, rename it and instantiate an instance of this which handles the Activities and Windows for the second display. • All Stake holders need to interface with two Window Managers

  16. Pros Cons • Simple concept with only minor changes to the actual implementation of the WindowManagerService; Standard WindowManagerService requires nearly no changes • Easy to migrate to next version of Android • Synchronization of both WindowManagerService instances required in some parts • Code duplication • Increased memory usage due to a second instance of the service • A number of stakeholders of WindowManagerService need to be modified • Not too attractive solution from architecture point of view

  17. Teleca’s experience in Dual Display for Android (6)- Design Approaches for Window Manager Support • Second Window Manager Service Instance • This concept proposes to modify the WindowManagerService and the IWindowManager.aidl code so that it can be instantiated twice. Each instance of the service would be responsible for one display then. The required changes haven’t been analysed in detail as this seemed to be more effort compared to previous approach. However from an architecture point of view this seems to be preferred. • The problem with this approach might be that the decision which WindowManagerService needs to be used might not always be possible and thus requiring modifications in the stakeholders. As a result the other approach was chosen

  18. Agenda • Introducing Teleca • History of Multi Display • Dual Display Mobile Devices • Teleca’s experience in Dual Display for Android Devices • Specific Implementation Details • QA

  19. Teleca’s experience in Dual Display for Android- High Level Block Diagram Applications Gallery Home 2 … OpenGL Application App. on second display Home Phone Application Framework Activity Manager … Window Manager 2 Window Manager View System Libraries Android Runtime bionic Surface Flinger OpenGL Hardware Abstraction Layer … Pico DLP Keyboard Driver Display Driver 1 Linux Kernel Touch Input 2 Touch Input 1 Display Driver 2 New Not feasible Modified

  20. Teleca’s experience in Dual Display for Android - Changes across the Android Stack • Applications • Extensions to the AndroidManifest.xml The AndroidManifest.xml was extended to support the attribute “android:display” for the <application> and the <activity> tag. The possible values are integer values, usually only used when the application or an Activity of the application wants to go on the second screen • Sample: <application android:label="@string/app_label"android:icon="@drawable/ic_launcher_alarmclock"android:display="1">

  21. Extension to the applications resources • The interface of the resources was extended to allow an application to set the display programmatically. This is usually done in the onCreate() of an Activity: protected void onCreate(Bundle icicle) {super.onCreate(icicle);getResources().setApplicationDisplay(Display.DISPLAY2);} • The class Resource was extended with two interfaces: public intgetApplicationDisplay(); public void setApplicationDisplay(int display);  • The display values are defined in Display.java as: Display.DEFAULT_DISPLAY Display.DISPLAY2

  22. Activity Manager • The Activity Manager starts an Activity and as such needs to know onto which display an application wants to go. The Activity Manager then adds the Activity onto the Window Manager’s proper Activity stack.  • The ActivityManagerService was extended by a number of changes: • Additional list of history entries for the second display which stores the stack of launched activities • Reference to WindowManagerService for the second display • Support to start, stop and resume activities for the second display • Support for separate Home Screen on second display. The second Home Screen itself was not implemented during the project.

  23. Window Manager • The Window Manager needs extensions to support two application/Activity stacks and two Window stacks. Additionally it needs to be made second display-aware. • Touch Events • Key Events • Rendering

  24. Applications Application 2 Application 1 Application 3 Application Framework Surface Surface Surface Surface Surface Libraries Surface Flinger Hardware Abstraction Layer Linux Kernel Clamshell Driver Display Driver 1 /dev/graphics/fb0 Display Driver 2 /dev/graphics/fb1 • Surface Flinger

  25. The standard Surface Flinger was extended two handle two stacks of layers, one for each display. Internally the Layers contain the buffer to be rendered. Additionally all the calls to OpenGL set the right OpenGL context before so that the OpenGL calls go to the right display. • From the applications point of view the decision onto which display is drawn is done by the display parameter set in the Surface object. The applications don’t do this directly though. They define this either in the AndroidManifest.xml or by setting the display in the associated resources by a direct API call. • The Activity Manager then decides onto which display an Activity wants to go and adds it to the correct Window Manager. The Window Manager then sets the proper display in the Surface object. • Access permissions • To access the Surface Flinger the following permission is defined in the platforms AndroidManifest.xml (in frameworks/base/core/res/): • android.permission.ACCESS_SURFACE_FLINGER • The following public constructor of Surface is hidden from the SDK and requires this permission: • public Surface( SurfaceSession s,intpid, int display, int w, int h, int format, int flags)throws OutOfResourcesException;

  26. Linux Kernel / Drivers • /dev/graphics/fb0 – Framebuffer for default display • /dev/graphics/fb1 – Framebuffer for second display • /dev/input/event0 – HW keyboard • /dev/input/event1 – Touchable first display • /dev/input/event2 – Touchable second display

  27. Agenda Introducing Teleca History of Multi Display Dual Display Mobile Devices Teleca’s experience in Dual Display for Android Devices QA

  28. Resourcefully yours

More Related