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

Deprecated:: 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

Deprecated:: 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

Deprecated:: Knox 3.8

Classes

Enumerations

Detailed Description

Enumeration Type Documentation