+## Software Architecture
+
+The static relationship with other components is shown below.
+The actual logic of Window Manager is the binding in Binder(afb-daemon).
+Window Manager is based on AGL application framework,
+so the IPC via websocket is protected by AGL application framework.
+
+The upper binder is for the application side security context.
+The lower binder is the Window Manager for the server side security context.
+Usually an application side binder has some business logic for each application, so the number of binders depend on the number of applications which use Window Manager.
+On the other hand, regarding lower binder there is only one module in the system. This binder receives messages from multiple applications.
+
+An application can use libwindowmanager.so to call Window Manager API simply.
+
+Window Manager is based on the GENIVI layer management system.
+
+![wm_software_stack.png](parts/wm_software_stack.png)
+
+### Layers
+
+Layers are entities that means the application stack group defined in `layers.json`.
+This doesn't mean layer ID defined in GENIVI ivi layer.
+The layer ID is used for application itself in Window Manager.
+Currently, application can't have multiple surfaces in Window Manager.
+
+### Surfaces
+
+Surfaces are *placed* on layers . The surface
+will then be resized to dimensions, according to the name of `areas.json`
+application requests by `activateWindow` or policy management.
+As default, `normal.full` is set by libwindowmanager for native application.
+
+### Configuration
+
+The window manager is configured with the *layers.json*, *areas.json*, *roles.db* configuration
+files. By default they are searched in `${AFM_APP_INSTALL_DIR}/etc/`.
+
+Sample configurations are provided with the window manager
+implementation, these samples are installed to ${AFM_APP_INSTALL_DIR}/etc/ .
+
+This configuration is supposed to be configured by policy designer which means OEM or Tier1.
+
+#### layers.json
+
+`layers.json` has three roles.
+
+1. Create application containers `Layer`.
+1. Set id range for applications.
+1. Attach application to `Layer` according to the role application requests.
+
+The sample configuration is here
+
+```json
+{
+ "comment": "Surface ID to Layer ID mapping",
+
+ "main_surface": {
+ "surface_role": "HomeScreen",
+ "comment": "This surface should never be made invisible (The HomeScreen)"
+ },
+
+ "mappings": [
+ {
+ "role": "BackGroundLayer",
+ "name": "BackGroundLayer",
+ "layer_id": 999,
+ "comment": "Single BackGround layer map for the map, radio, music and video"
+ },
+ {
+ "role": "homescreen",
+ "name": "FarHomeScreen",
+ "layer_id": 1000,
+ "comment": "FarHomeScreen is the part of HomeScreen. The z order of this layer is lower than NearHomeScreen"
+ },
+ {
+ "role": "music|video|browser|radio|phone|map|hvac|settings|dashboard|poi|mixer|sdl|launcher|fallback",
+ "name": "Apps",
+ "layer_id": 1001,
+ "comment": "Range of IDs that will always be placed on layer 1001"
+ },
+ {
+ "role": "^on_screen.*",
+ "name": "OnScreen",
+ "layer_id": 9999,
+ "comment": "Range of IDs that will always be placed on the OnScreen layer, that gets a very high 'dummy' id of 9999"
+ }
+ ]
+}
+```