rkimage-encrypt-support.md

+## Encryption Support
+Full Disk Encryption is nearly invisible in Android.  The only area that is directly impacted is the ability to deliver ota updates.
+
+OTA updates can be delivered as incremental or full image updates.  The incremental updates are cumbersome for Buzztime, because we prefer to deliver content as a manifest to tablets without regard for the tablet state.  An incremental update would mean that a tablet must get a specific delta from it's current version to the next version. The build system would need to keep the detailed builds to use to create the delta's.  As a result, we simply deliver a full ota update for any firmware refresh.
+
+The full ota update is about 600Mb, zipped it will drop to 300Mb, but then require 900Mb (300Mb zipped + 600Mb unzipped).
+
+There are 3 storage locations available for the update.  The cache partition, the internal sdcard, external sdcard slot.  We do not fill the external sdcard slot and permissions on it are restrictive for writing.  The normal external sdcard scenario would be to write the update file on a PC, then insert the sdcard to apply the update.
+
+The leaves the internal sdcard and the cache.  The cache would require increasing it's size from 50Mb to 3/4 - 1 Gb to hold the full update image.  This storage would be exclusively dedicated to firmware updates.  With 8Gb total eMMC space and only 5Gb available, that would amount to a 20% hit to overall storage on each tablet.
+
+That leaves the internal sdcard.  This space is available and reusable, so it is the most efficient storage arrangement for the infrequent need to apply a firmware update.  The problem is that with full disk encryption enabled, all files on the internal sdcard are encrypted.  When the systems boots into recovery mode to apply the firmware update, disk encryption is not enabled for security reasons.
+
+For straight AOSP updates, the situation is handled with a hook in the recovery-reboot process.  When the device sees it is rebooting into recovery to apply a firmware update, the file is decrypted in place and the lowlevel block map for the file is preserved in the cache.  The is the reason for the long pause in the [Reboo] dialog.   When the system reboots into recovery, it identifies the state and loads the file by mapping the block map directly.  Then it can apply the update with the previously decrypted update contents.
+
+For Rockchip builds, this work has not been implemented.  meaning that updates can only be delivered on unencrypted systems, or by applying an update from insertable media.  We are left with the task of implementing the AOSP update process to the Rockchip rkimage file format.
+
+