The Application Execution Environment (AEE), in which all Brew applets are executed, the file system, fonts, multimedia content management, players and listeners, locales, and memory management.
Application management in Brew MP entails the control functions of starting and stopping apps, loading apps from filenames or URLs, obtaining information like state (foreground, suspended, background) and class ID about a specific application, and interacting with the app history stack; in other words, the lifecycle of a running app. Application management also provides an interface to applet history (e.g., suspended app stack) so that Brew MP apps can access the history and navigate through the stack to obtain information about suspended apps.
File system capabilities under Brew MP are standard: create, enumerate, rename, delete and get properties of directories and files. Each module has its own section of the directory tree that is a home file system space (fs:/~/). Access Control Lists (ACLs) work at the directory or file level and allow modules to specify privileges required to read/write files in their home directory. Just like other privileges, ACL privileges are signed as part of the MIF, and modules with sufficient privileges can access other, module-owned files at fs:/~ /. fs:/shared/ acts as a system-wide shared directory, such that all apps can read from and, with permission, write to it for use in storing user's files, for example. Multimedia Content File (MCFs) are file system aliases that developers can use and OEMs can map to as a location for certain file types (e.g., photos, videos, music) when stored in different places. Apps can register with the file system for notification of external memory devices, in case they need to refresh indexes. OEMs can configure file caching differently among devices and factor it into the overall memory budget.
Centralized memory management services allow applications and modules to allocate, re-allocate and free up memory, using functions with c-stdlib syntax so that applications can use the same heap without having to create object instances for dealing with memory operations. Brew MP tracks memory by module, re-using any leaked memory to protect the system heap. It detects any un-released memory and automatically frees it when the module is released (i.e., when the ref count of the module goes to zero). By default, malloc() zero-initializes all allocated memory, but developers can disable this with the ALLOC_NO_ZMEM flag for better bulk-allocation performance. The platform manages memory on a per-process basis, and each process has a heap that grows until it reaches the limit specified by the definition of that process.
The range of system services includes OS services, time/timer management, diagnostic logging, inter-app and inter-process communications. IEnv is the hosting environment for most objects and provides the basic set of services a component requires to be instantiated and initialized (memory allocation and creation of other objects). In Brew MP, apps don't need to be loaded and running in memory to receive notifications; they can be unloaded to free up the memory until the notification comes from lower layers (messaging, telephony, flip open device), then reloaded only when needed in response to the
The platform provides specific interfaces for managing ringers and wallpapers, and a generic settings framework for system-wide and application-specific management of settings. The framework allows multiple apps to share common settings data; e.g., one app may configure a setting and another alters its behavior based on that setting. Changes to settings do not alter the default setting, so that, if necessary, users can roll back to factory default using refurbishment support. The framework provides for notification of changes (e.g., to themes) and for .ini-file settings that persist across device resets and power cycles.