* rework of the build structure, adopt to standard cmake package structure7.4

* check versions when loading the libs
* introduction of the AudioManagerCore
* give control plugin as file or directory
* remove SQLITE
* either find and use gmock or build and install it
* fixed [Bug 411]
* compile flag gnu11 is now used

Signed-off-by: Christian Linke <Christian.Linke@bmw.de>

Signed-off-by: Christian Linke <Christian.Linke@bmw.de>

1 files changed, 0 insertions, 99 deletions

diff --git a/AudioManagerDaemon/docx/04_components.dox b/AudioManagerDaemon/docx/04_components.dox
deleted file mode 100644
index 7c8f9b4..0000000
--- a/AudioManagerDaemon/docx/04_components.dox
+++ /dev/null
@@ -1,99 +0,0 @@
- /*
- * Copyright (C) 2012, BMW AG
- *
- * This file is part of GENIVI Project AudioManager.
- *
- * Contributions are licensed to the GENIVI Alliance under one or more
- * Contribution License Agreements.
- *
- * \copyright
- * This Source Code Form is subject to the terms of the
- * Mozilla Public License, v. 2.0. If a  copy of the MPL was not distributed with
- * this file, You can obtain one at http://mozilla.org/MPL/2.0/.
- *
- * \\author Christian Linke (christian.linke@bmw.de)
- *
- */
- 
- /*!
- \page audiomanagercomponentspage AudioManager Components
- \image html AudioManagement.png
-
- The AudioManager is the central managing instance of the Audio architecture. It is designed as an OwnedComponent, this means that the
- software is maintained within GENIVI as open source component. The AudioManager consists of 4 central components.\n
-
-
- \section audiomanagercomponents AudioManagerDaemon
-
- This component is owned and maintained by Genivi. It is the central audio framework component. There can be only one daemon in a system (singleton).\n
- The AudioManagerDaemon is subject to this documentation.
- \subsection daemonover Daemon Overview
- Here is an class overview of the AudioManagerDaemon:
- \image html daemon_insight.png
-
- \section commander AudioManagerCommandPlugin
-
- This describes the interface towards the Commanding Instances of the AudioManagerDaemon. This is the HMI and interrupt sources that use this
- interface to start their interrupt and stop it again. The interface shall be asynchronous. Via this interface all user interactions are handled.
- This component is designed to be a dynamic linked library that will be loaded on the startup of the AudioManager. There can be more than one
- CommandPlugin at a time.
- Since the implementation of this component is project specific, only examples are included.\n
- An example Dbus Implementation can be found in the folder PluginCommandInterfaceDbus.
-
- \subsection commandIface Interfaces
- All commands that must be fulfilled by an AudioManagerCommandPlugin are described in am::IAmCommandSend.\n
- All commands that are presented to AudioManagerCommandPlugin by the AudioManagerDaemon are described in am::IAmCommandReceive.\n
-
- \section controller AudioManagerController
- The controller is the intelligent "heart" of the AudioManager and it is project specific. In principle, the controller gets commands from the command
- interface or events from outside and reacts to them. For this purpose, some basic commands are in the "toolbox" of the Controller that he can use
- to interact with the rest of the system.\n
- Among this there are commands to read/write the database and to perform actions on the Audiodomains like connect or disconnect. There must be only one
- Controller in the system at a time, like the AudioManagerCommandPlugins, the Controller is loaded at startup by the daemon\n
- A simple example Implementation can be found in the folder PluginControlInterface.
-
- \subsection controlIface Interfaces
- All commands that must be fulfilled by an AudioManagerController are described in am::IAmControlSend.\n
- All commands that are presented to AudioManagerController by the AudioManagerDaemon are described in am::IAmControlReceive.\n
-
- \section router Routing AudioManagerRoutingPlugin
-
- The AudioManagerRoutingPlugins are used to abstract the actual Hard- and Software that does the routing. There can be more than one plugins at a
- time, they are loaded at startup time like the commandplugins. \n
- The AudioManager expects a bus-like structure behind each plug-in, so that a plug-in can implement a bus interface and proxy the messages to the
- routing adapters - the AudioManager is capable of addressing more than one adapter one each plug-in. The AudioManagerController does not have to
- know anything about the real system plugins - he sends his commands to sources and sinks. The daemon does the dispatching of these commands.
- The interface is mainly asynchronous.\
- Sample plugins can be found in the directory, for example PluginRoutingInterfaceAsync.\n
-
- \subsection routingIface Interfaces
- All commands that must be fulfilled by an AudioManagerRoutingPlugin are described in am::IAmRoutingSend.\n
- All commands that are presented to AudioManagerRoutingPlugins by the AudioManagerDaemon are described in am::IAmRoutingReceive.\n
-
- \subsection subrouter Bus topology
- The AudioManagerDaemon expects a bus behind each of the plugins. On one of these buses there can be several domains. In order to
- reflect this, a domain has always a bus(plugin) and a node that it belongs to. So if a message needs to be transmitted to a domain,
- it will always be sent to a node on a bus.
- Here is a diagram showing the topology from the view of the AudioManagerDaemon:
- \image html bus_topology.png
- \subsection busname Busname
- Since a plugin represents a bus for the AudioManagerDaemon, each plugin it has its unique name, the busname that is returned by
- am::IAmRoutingSend::returnBusName. The AudioManagerDaemon used this information to link a plugin with a domain. All other elements like
- sinks, sources etc are linked to domains. This is how the hierarchy looks like that is used:
- \image html routing_hierarchy.png
- 
- \subsection CAPIplugins CommonAPI plugins
- As "sample code" with MIT license, PluginCommandInterfaceCAPI and PluginRoutingInterfaceCAPI are provided with the source code. The FRANCA 
- fidls have been generated out of the Enterprise architect model, so they might be used to draw project specific behavior in sequences.
- The sources in src-gen have been generated out of the provided fidl files.
- 
- \image html PluginCommandInterfaceCAPI.png
- 
- \image html PluginRoutingInterfaceCAPI.png
- 
- There is no fixed domain associated with this plugin. So you have to implement the interface org::genivi::am::RoutingControlStub and report
- busname and path to the routingplugin on the interface org::genivi::am::RoutingControlObserverStub like this:
- 
- \image html Register_Domain.png
-
-*/