Classes
struct	PixelFormatDetail
	This structure provides the pixel format information in terms of actual component offsets. More...
class	DirtyRegion
	This structure provides the Dirty Region Information. More...
class	IRemoteDesktopListener
	This class provides the interface to get notified when the screen changes. More...
class	IRemoteDesktop
	Remote Desktop Module provides means by which the admin capture the device screen content. More...
Enumerations
enum	FDType { FD_INVALID, FD_DEV_FB0, FD_SHARED_MEM }
	This enum provides the different file descriptor types. More...
enum	{ PF_UNKNOWN, PF_RGB_565, PF_BGRA_8888, PF_RGBA_8888 }
	This enum provides the different pixel formats for the device screen. More...

Detailed Description

Mobile Communication Division, Digital Media & Communications Business, Samsung Electronics Co., Ltd.

This software and its documentation are confidential and proprietary information of Samsung Electronics Co., Ltd. No part of the software and documents may be copied, reproduced, transmitted, translated, or reduced to any electronic medium or machine-readable form without the prior written consent of Samsung Electronics.

Samsung Electronics makes no representations with respect to the contents, and assumes no responsibility for any errors that might appear in the software and documents. This publication and the contents hereof are subject to change without notice. Remote Desktop Module provides means by which the admin capture the device screen content.

It provides the following features for EDM client

Access to screen content through shared memory from Surface Flinger.
(Note: Surface Flinger is android's composition engine that composes the UI content and updates to the display
or Access to screen content through Read-only access to the framebuffer device.
Screen Changed Notifications
( This prevents the EDM client from having to poll the screen content continuously to check for changes. The notifications shall be received for both approaches fb0 and surface flinger.)
Dirty Region feedback after capture

The decision to use framebuffer device (fb0) or Surface Flinger mechanism is made based on the following aspects

Availability of the approach
(Eg: - Only Surface Flinger approach works in some devices as the frame buffer device is not accessible/available),
Frame rate yielded by individual approach and
Accuracy of the screen content
(Eg: - FB0 misses some overlay content. Lets say, Wallpaper is present in one layer, Status Bar present in one layer, remaining UIs present in another layer).
Note: This decision is done for every device at build time.

The EDM client can register a listener to receive notifications when the screen changes. On occurrence of screen change, the Remote Desktop module sends a screenChanged callback and waits for the capture request from the client. (Note: Subsequent screen changes are detected, but they are not notified to the client until the capture request for the outstanding callback is received.)

In case of Remote Desktop session
  1) If Remote Desktop Session is started at owner space
      a) It can capture owner space screens
      b) It can capture Android guest user's screens

  2) If Remote Desktop Session is started at Android guest user
      a) It can't capture owner space screens
      b) It can capture its own user space screens

Events injected by Remote Injection are not injected into user space where Remote Desktop is disabled.

PolicyGroupID:: Remote Control

Since:: API level 3; MDM 2.1

Deprecated:

API level 35

Knox 3.8

Permission:: This policy requires the caller to have the "com.samsung.android.knox.permission.KNOX_REMOTE_CONTROL" permission which has a protection level of signature.

Enumeration Type Documentation

anonymous enum

This enum provides the different pixel formats for the device screen.

Pixel formats depend on the support from underneath capture mechanism (framebuffer device (fb0) or Surface Flinger mechanism)

1. In Surface flinger based capture, RGBA_8888 will be the output format.

2. In FB0 based capture, formats BGRA_8888 and RBG_565 are so far supported because these were the known formats in so far tested devices. If the FB0 device provides content in any other format than these formats in future devices, then it would be marked as PF_UNKNOWN. But still the EDM client can use ioctl directly like below to fetch the colour offset information:

	    remoteDesktop->getScreenInfo(&width, &height, &bytesPerPixel, &pixelFormat);
		if (mFDType == FD_DEV_FB0 && pixelFormat == PF_UNKNOWN) {
			// Special Case
			struct fb_var_screeninfo var;
			if(ioctl(mFD, FBIOGET_VSCREENINFO, &var) < 0) {
				LOGE("Failed FBIOGET_VSCREENINFO");
				return;
			}
			//The following information shall be used to render the buffer
			int redoffset = var.red.offset;
			int redlength = var.red.length;
			int greenoffset = var.green.offset;
			int greenlength = var.green.length;
			int blueoffset = var.blue.offset;
			int bluelength = var.blue.length;
			int alphaoffset = var.transp.offset;
			int alphalength = var. transp.length;

		   // Code to read the buffer in this special case using above color offset information
		} else {
			// Code to read the buffer in normal case
		}

Since:: API level 3; MDM 2.1

Deprecated:

API level 35

Knox 3.8

enum knoxremotedesktop::FDType

This enum provides the different file descriptor types.

File Descriptor types depend on the underneath capture mechanism. (framebuffer device (fb0) or Surface Flinger mechanism)

Since:: API level 3; MDM 2.1

Deprecated:

API level 35

Knox 3.8

Classes

Enumerations

Detailed Description

Enumeration Type Documentation