- Terms Used in Kernel Builds
- What is the difference Between HAVS and SVS?
HAVS changes the voltages used for each frequency, SVS has fixed voltages. HAVS should give better battery life, SVS should be more stable. Using lower voltages or higher frequencies can make your phone unstable.
- What is the difference between CFS and BFS?
You could write a thesis on this, in fact this is pretty close to a thesis. For those that just want a little knowledge, both are CPU schedulers, that attempt to schedule multiple processes so they get an appropriate slice of the CPU resources. CFS outperforms BFS in minimizing process turnaround time but BFS outperforms CFS for minimizing latency. This indicates that BFS is better for interactive tasks that block on I/O or user input (like your phone) and CFS is better for batch processing that is CPU bound. CFS generally seems more stable in . At least one user has found that BFS makes video playback with Rockplayer (and probably other Video players) jumpy. BFS may also cause occasional jumps in audio playback.
- What is AXI and NOAXI?
The memory throughput is directly proportional to the AXI (internal bus) frequency. For AXI builds, the AXI freq is coupled with the CPU freq to prevent the memory from being the bottleneck when the CPU is running at one of its higher frequencies. This will cause an increase in power consumption when the CPU is running at higher frequencies, but will give a better performance/power ratio [hugonz]. AXI should further reduce the battery usage when the screen is on. However, 128Mhz IS INCOMPATIBLE WITH THIS!!!. So if you want to use the AXI patch, use SetCPU and define a profile that sets the minimum speed to 256Mhz when the screen is on, and sets it back to 128Mhz when the screen is off. This is NOT necessary with the ManU kernels as it is done automatically by the kernel. [EViollet]
- What is the difference between BFQ, VR, SIO, NOOP and Deadline?
These are I/O schedulers. VR is supposed to be the best for Android see this
- What is the difference between SLUB, SLAB, SLOB and SLQB?
These are slab allocators. The slab allocator has been at the core of unix kernel’s memory management for many years. This allocator (sitting on top of the low-level page allocator) manages caches of objects of a specific size, allowing for fast and space-efficient allocations. Kernel hackers tend not to wander into the slab code because it’s complex and because, for the most part, it works quite well. SLQB seems to be favoured by most AOSP kernels. Detailed article here
- What is the difference Between HAVS and SVS?
- What are DATA2EXT (D2E) and DATA2WHATEVER (D2W)?
(Thanks to Dani for this)
Moving the whole /data system partition onto the SD card was the original concept by darkstrumn named data2sd. The first developer (ownhere) who wrote a stable script that moved /data to the SD card called it data2ext (now don’t get confused, there are other versions, but this one moves it to sd ext partition not the sdcard FAT32 partition). All implementations requires a primary FAT32, then a primary EXT (and that depends on their script, plus many other factors). But basically what they want is to move /data into the EXT partition of your card so people will have HUGE Internal phone memory whatever they choose. Though there are limitations, particularly don’t partition EXT more than 2GB.
Another developer (melethron) decided to make it more flexible in moving the /data structure and called it DATA2WHATEVER!!! The main difference is that the partition can be EXT2, EXT3, EXT4, BTRFS, Reiserfs, and it is still evolving right now i dont know where it will end.
The name only implies it can work with any partition, but there are still issues about sdcard speed and type, and more.
For most of us, We use EXT3 as partition. I tried ext2, ext4, reiserfs, btrfs, and my sdcard is not liking it. So i stick with EXT3. It’s up to you what to use though.
Conclusion: DATA2SD and DATA2EXT are the same thing, and require an EXT3 partition. DATA2WHATEVER can supposedly use many differents formats for the partition.
- Some advice if you are trying the Data2Anywhere experimental version.
Melethron has suggested here to avoid using reboot.
- DON’T use the reboot of snq’s powermenu (or any other reboot app)
- DON’T use anything in the “ROM Manager” that makes it reboot.
- DON’T do adb reboot / abd reboot recovery / adb reboot bootloader
- DON’T pull the battery while the phone is on (this should be obvious)
- DON’T remove the “sync” mount options for the Quadrant “boost” (this is a fake boost anywa
- All of the above are like a powerloss for the sd-card and have a high change of data corruption
- From my test with this I give you an estimate what can happen if a powerloss occurs or any of the 5 points above happen:
- 50% general chance of corruption that will be autofixed on boot (not a problem)
- 10% chance of forcecloses after reboot of some apps (this can be fixed by deleting the app data or restoring it with titanium (or other) backup)
- REALLY tiny chance (didnt happen for me in over 40 “simulated” powerlosses) that partition gets corrupted (needs complete repartitioning of the microSD so all data on it will be gone then)
- As long as you watch the 5 points above and as long as you don’t drop the phone and the battery jumps out this will be safe
- What is Busybox?
An application providing a standard set of unix tools. The default toolbox provided by android is limited, so this is required to allow rooted roms/apps to use more advanced unix features. Busybox is included in most custom ROM’s including -Au.
- What is the Dalvik-cache?
When your phone starts up, the Dalvik Virtual Machine looks at all your apps and frameworks, and creates a tree of dependencies which is stored in the dalvik-cache. This allows applications to run in an optimised state (and explains why your phone takes longer to boot up after applying a new rom, it’s rebuilding the cache.) Dalvik cache is typically 40+Mb and you can read more on the Dalvik VM here and here. BTW apparently the author has ancestors from Dalvik, Iceland (or so the story goes).
Zipalign is an archive alignment tool in the Android SDK that provides important optimization to Android application (.apk) files. The purpose is to ensure that all uncompressed data starts with a particular alignment relative to the start of the file. The benefit is a reduction in the amount of RAM consumed when running the application.
- ODEX – DEODEX?
.DEX files are compiled-code versions of APKs that are created on-the-fly by Android, namely by Dalvik VM, hence the name: *D*alvik *EX*exutable. ODEX are Optimized DEX files that are created ahead of time for System apps with the DexOpt SDK tool. The benefit is that these apps start up faster because of the optimization. The drawback is that the APK that’s been ODEX’ed will not work without the corresponding .odex file present, which almost doubles the size of the app. Deodexing means you convert it back to a .dex file and put it back inside the apk. This allows the programmer to easily replace files (not having to worry about odexes), but the main point was to deodex services.jar so that programmers can change all text to different colors (such as the clock color to white) and to deodex services.jar, you need to deodex everything.
- Can I include HTC sense modules in by adding them to the ROM before flashing?
Unfortunately, you can’t just grab any of the HTC Sense apps as they usually rely on the Sense framework to work properly (which is why we can’t have HTC’s camera app, and HTC’s FM radio).
Leave a Reply
Using Gravatars in the comments - get your own and be recognized!
XHTML: These are some of the tags you can use:
<a href=""> <b> <blockquote> <code> <em> <i> <strike> <strong>