1 /* 2 * Copyright (C) 2014 The Android Open Source Project 3 * 4 * Licensed under the Apache License, Version 2.0 (the "License"); 5 * you may not use this file except in compliance with the License. 6 * You may obtain a copy of the License at 7 * 8 * http://www.apache.org/licenses/LICENSE-2.0 9 * 10 * Unless required by applicable law or agreed to in writing, software 11 * distributed under the License is distributed on an "AS IS" BASIS, 12 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 13 * See the License for the specific language governing permissions and 14 * limitations under the License. 15 */ 16 17 /** 18 \mainpage DMT Plugin API Documentation 19 20 \section Overview 2.0 Overview 21 22 \warning This file is for internal usage only!!! 23 24 The Device Management implementation is based on the OMA DM (Formerly called SyncML DM) 25 Standard. A core part of implementation is the Device Management Tree (DMT). Each device that 26 supports OMA DM must contain a management tree. This document describes API required for 27 access and control DMT. \n 28 Nodes are the entities which can be manipulated by management actions carried over the OMA DM protocol. 29 A node can be as small as an integer or as large and complex as a background picture or screen saver. \n 30 31 The DMT constitutes a universal management data access mechanism. 32 However, in the OMA DM standard, the DMT is only defined logically, 33 that is, it does not define how the nodes are stored or where they come from; 34 therefore, in our implementation, there are two kinds of tree nodes physical 35 and logical. Physical nodes are easy to understand all nodes together with 36 their configuration data are physically persisted and stored. 37 This is similar to the MS Windows registry. However not all management information 38 can be covered by such a data repository. \n 39 40 The information either is too dynamic or already exists in the system and cannot 41 be duplicated in the DMT. However, these nodes can still appear in the DMT, and 42 are referred to as logical nodes. \n 43 44 For example, in the P2K DM engine, all of the nodes in the tree were logical that is, 45 configuration data was stored by each application on the phone, and the DMT was a logical 46 representation of that data. \n 47 48 The DM Engine supports both physical nodes and logical nodes. Different platforms may 49 choose different approaches. To access these logical nodes, the DM engine supports a 50 plug-in architecture, which allows libraries to be added to the DM engine for accessing 51 nodes that are not physically in the tree. By using the data plug-ins, the DM engine can 52 support those logical nodes. \n 53 54 This plug-in architecture also allows for libraries that are used to enforce integrity 55 constraints on the nodes in the tree, as well as execute plug-ins which allow commands or 56 pointers to applications to be stored in DMT nodes. \n 57 58 The DM engine plug-in mechanism is designed to allow uniform access to both the built-in 59 configuration repository and other types of management data. \n 60 61 Data plug-ins can be written in both C++ and Java and their interface is an extension of 62 the public DMT API. For details, refer to the DMT API Documentation. 63 Native data plug-ins are separate libraries (in an OS environment allowing for such), 64 deployed in a well-known directory along with their internal configuration files. 65 The files describe the sub-tree(s) of the DMT claimed by the plug-in, as well as, 66 optionally, its internal configuration information for the nodes it is responsible for. 67 68 69 \section IndustryStandard 3.0 Industry Standard 70 71 OMA DM (formerly SyncML DM) 72 73 \section ClassAndStructureDefinitions 5.0 C++ Class and Structure Definitions 74 75 \subsection Classes 5.1 Classes 76 -# DMSubscriptionVector <em>DM Subscription Vector, inheritance from DMVector </em> 77 -# DmtAPIPluginTree <em> Device management plugin tree API class; inheritance from DmtTree </em> 78 -# DmtOPINodeData <em> Engine side support for Overlay plug-ins including meta node ID and PD retrieval </em> 79 -# DmtOverlayPluginSyncData <em> Overlay plugin synchronization data </em> 80 -# DmtPluginNode <em> Class DmtPluginNode for default read only plugin node implementation </em> 81 -# DmtPluginTree <em> Has parent DmtAPIPluginTree class; handle operation with nodes and other tasks </em> 82 -# DmtRWPluginNode <em> Based plugin node class with read/write functionality, inheritance from DmtPluginNode </em> 83 -# DmtRWPluginTree <em> Based plugin tree class with read/write functionality, inheritance from DmtPluginTree </em> 84 85 \subsection Structures 5.2 Structures 86 Details of the structures are available from the source header files directly: 87 -# dmtCommitPlugin.hpp 88 -# dmtPlugin.hpp 89 90 \section CFunctionsAndDataTypes 6.0 "C" Functions and Data Types 91 -# const DmtOPINodeData* DmtGetCachedOPINodeData() <em>For the internal usage only!This function should be called only from the plug-in "getNode" function</em> 92 -# SYNCML_DM_RET_STATUS_T DmtSetOPINodeData( CPCHAR szURI, const DmtOverlayPluginData& oData ) <em>For the internal usage only! Allow to update plug-in data in DMT</em> 93 94 \section HeaderFilesAndLibraries 7.0 Header Files And Libraries 95 96 -# dmtDefs.h 97 -# dmtError.h 98 -# dmtCommitPlugin.hpp 99 -# dmtPlugin.hpp 100 -# dmtRWPlugin.hpp 101 -# xpl_Types.h 102 -# xpl_StringUtil.h 103 104 \section PluginExtensionPointInterface 8.0 Plug-in Extension Point Interface 105 106 "None" 107 108 \section OtherInterfaces 9.0 Other Interfaces 109 110 "None" 111 112 \section OtherNotes 10.0 Other Notes 113 114 - All APIs' functions are synchronous. 115 116 - All APIs are in the "Final" state and guaranteed backward compatibility. 117 118 - All APIs are not secured but protection enforced on the DMT subtree level. 119 */ 120
