Forums | Forums |



A word of warning to those of you using MOD-compressing solutions -- this may cause your application to fail the disable/restore testing during disable/restore testing. We've started seeing a few TBT failures caused by the apparently increasing popularity of these solutions.

During the disable process, BREW creates a list of applications in order of least recently used. BREW then advances through the list, adding the packages to the disable list until the desired amount of space is freed. After enough space has been reclaimed, BREW moves backwards through the list and removes packages from the disable list if enough space is freed without inclusion of that specific package. There are two distinct quantities in package size calculations: the application size and the data size (where total size = application size + data size). For all disable list calculations, BREW uses the application size – as the files removed during the disable process are those ending with .MOD, .BAR, and .SIG. Application size is currently defined as the sum of all file sizes for files in the directory ending in a .MOD or .BAR extension (while data size is calculated by summing the filesizes for all files not ending in .MOD or .BAR). Consequently, packages containing a very small application size will nearly always be removed from the disable list. Disabling these applications is likely to leave a large amount of residual files on the device, as none of the files counted in the data size are removed during disable (to protect data created at runtime, such as configuration files).

To work around this restriction, use the .BAR file extension for resource files when possible (even if these files are not internally in the BAR format) or compress into a .MOD file.