Project OtterX: New Direction
** WARNING. WORK-IN-PROCESS DISCUSSION. NO ETAS. NO DONATIONS. NO PROMISES. **
I've been considering some major changes
to the otter device (Kindle Fire 1st Ed.) and I'm going to open this up for discussion.
The direction I'm going is called: OtterX.
It's a major change to the device. If you choose to update, it won't be easy to flash back the stock files and use your device as a Kindle again. The device name will actually change to "otterx", so that the 2 sets of files can be kept clearly distinct as well as provide a safety net for those who accidentally download the wrong thing and try to flash it.
QUESTION: What do you use your Kindle for?
I can think of at least 3-4 different kinds of users out there.
1. Kid's tablet.
Let's face it. This is probably the most common user out there today. And this can't be ignored. What they want: stability.
Hard to explain to Sally why her tablet turns off randomly or her games won't play.
2. Android tablet.
This is the next largest group of users who migrated away from Amazon's software due to limitations. What they want: features and usability. Newest Android ROMs.
3. Developer tinker toy.
Probably the smallest but in many way's the most interesting group. You have another tablet that you use. This is your dev toy. You want the latest linux kernel on it, or an Ubuntu distro. Use it as your car header unit, or touchscreen stereo interface. What they want: latest kernel and compatiblity. OTG, etc.
GOALS OF THIS PROJECT:
Make everyone happy of course.
Of course, the REAL end goal: to keep this device current and usable using today and future OS updates. And yes, maybe even get OTG and the MIC functions working.
- Update the bootloader (u-boot). And I don't mean "tweaks" to the bootloader, I mean: the current code was based on a 2011 release. The newer bootloader will be based on a 2014 release. Changes to be included in the update:
- A much better text driven menu system laid on-top of the initial boot graphic (as opposed to the image-only menus currently)
- Cleaned up device initialization / charging loop for extreme low battery situations
- Support devtree binary loading (native support for newer kernels)
- Support for decompessing kernels in new formats
- Native "reboot recovery" support no more hacky idme/sticky values
- Device "handling" changes like a longer button press to fully power on the device. Avoids "accidental" power ons while traveling.
- Built in support for "charger" mode. IE: plug the device in while it's off and it boots into the native Android charger screen, vs a full boot of Android.
- I'm guessing a new initial power-on logo as well (it won't say "KINDLE", I can promise that.)
- Partition layout change. I'm kind of done with only having 1GB of data space. The device is a perfectly usable tablet until you install a few games and notice you don't have any more room for apps. To fix this, the partition layout is going to be modified:
- xloader: same
- bootloader: same
- dkernel (10mb): space merged into userdata
- dfs (192mb): space merged into userdata
- recovery (16mb): resized to 10mb
- backup (64mb): space merged into userdata
- boot (10mb): same
- splash (5mb): turn into "efs" partition for storing rom-based personal info (some info to be pulled out of the idme table during initial ROM boot).
- system (512mb): same
- userdata (1137mb): combine with "media" partition which is after "cache"
- cache (256mb): partition will be placed ahead of the current "userdata" partition possibly increase size to 300mb for future compatiblity
- media (5131mb): turned into new "userdata" area (combine with old "userdata" and the space from the removed partitions for a total size of 6.4gb). This new area is used by Android as both app storage and emulated sdcard like most current Android devices. This will not only allow for more storage flexibility, but also support full encryption of device storage (where currently only the 1gb partition can be effectively encrypted in the OS).
- The process for changing the partition layout will be handled in the bootloader menu. Users will need to pull everything off the internal storage prior to performing the change as it will wipe system, cache and userdata partitions out during the process.
- Kernel update. A lot has happened to the OMAP kernel world over the last year. Much of the code needed to run newer kernels has been merged into the mainline. However, much has not. So I'm riding the line between: 1) finishing the 3.4 kernel using the new bootloader and partition layout, with an option for upgrading later to an even newer one. Drawback: I don't have a 512MB based ducati binary to process HD codecs for the 3.4 kernel. Or, 2) starting a newer kernel to go hand in hand with the other portions of this update (it would be 3.8 or newer). Why upgrade the kernel? Besides the typical "bigger better faster" mentality, I want some specific solutions to current problems: our graphics layer has been outdated for 1-2 versions of Android, and we still use a TI supplied ducati binary for HD codecs. If we update to a 3.8+ kernel, I can then attempt to build a custom ducati binary which would work better with our 512MB memory requirements and leave more free space to the OS.
1. Would you perform such an update knowing that you would have a hard time going back to the Amazon software. Who really uses their original Kindle Fire as a reader anymore anyway?
2. If I were to drop the partition layout change from this project do you think more users would like it? Or less?
3. I had considered a dual boot option to be built into the new menu system. But I think we just don't have the internal space for it. I'd rather have 1 VERY usable tablet, than a dual boot system which isn't as usable in either ROM. Thoughts?