riverboat2001
Well-Known Member
What is a Kernel?
Why are they so important?
What is a radio
De-odexed?
Zip aligned?
Why are they so important?
What is a radio
De-odexed?
Zip aligned?
-
After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.
[International / GSM] Can someone explain these rooting terms please
- Thread starter riverboat2001
- Start date
-
- Tags
- galaxy nexus
stenzor
Android Enthusiast
The kernel is basically the lowest level of software on any computing device.. It talks directly to the hardware and manages the cpu, memory, processes, etc.
From that you can see why a good kernel is important especially on mobile phones. A kernel with poor memory management and process management etc can lead to crashes, bad battery life, and a bunch of other problems.
The radio, apart from being the hardware piece, also needs a software component. That's what most people on here talk about when they say "flash the radio" etc. Another name for the radio software is baseband.
Android phones have several partitions on their flash memory where they store various stuff. Some of these are: the bootloader, radio, system for example. So your radio really can be replaced. When a new update for your OS comes out, it is usually prepackaged with the newest version of the radio. But if you're flashing different ROMs or different builds of the OS, you may have to flash different radios depending on where you live or how good your radio is performing.
From that you can see why a good kernel is important especially on mobile phones. A kernel with poor memory management and process management etc can lead to crashes, bad battery life, and a bunch of other problems.
The radio, apart from being the hardware piece, also needs a software component. That's what most people on here talk about when they say "flash the radio" etc. Another name for the radio software is baseband.
Android phones have several partitions on their flash memory where they store various stuff. Some of these are: the bootloader, radio, system for example. So your radio really can be replaced. When a new update for your OS comes out, it is usually prepackaged with the newest version of the radio. But if you're flashing different ROMs or different builds of the OS, you may have to flash different radios depending on where you live or how good your radio is performing.
BlueDC2
Android Enthusiast
From xda:
Deodexed ROMs have their .apk's (which are basically the application packages) repackaged in a certain way. An "odex" can be thought of as a collection of parts of applications that have been pulled out and optimized before booting. This speeds up the boot process - in a way, it preloads part of the applications - but it also makes hacking those apps difficult because part of the original code is already extracted somewhere else.
Deodexing is just a process of putting those pieces back into the original applications. It takes a while to extract those parts and build the .dex cache (aka Dalvik cache), but only because the relevant parts aren't in an easy-to-access place for the system. The advantage of this is that an app can be modified effectively and the developer doesn't have to worry about conflicts from the separate odex part of the code.
So, short version: "Deodexed" ROMs have all their apps put back together. If an app can be themed, for example, a deodexed version of that app will not get messed up when the modified .apk tries to mesh with the odex of the original un-modified .apk. Because it's not there.
If you want an aftermarket theme, you need a deodexed ROM. I'm not sure if deodexing can be done to individual apps within a non-deodexed ROM.
From the Android Developers Blog:
zipalign is an archive alignment tool 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. Specifically, it causes all uncompressed data within the .apk, such as images or raw files, to be aligned on 4-byte boundaries. This allows all portions to be accessed directly with mmap() even if they contain binary data with alignment restrictions. The benefit is a reduction in the amount of RAM consumed when running the application.
Deodexed ROMs have their .apk's (which are basically the application packages) repackaged in a certain way. An "odex" can be thought of as a collection of parts of applications that have been pulled out and optimized before booting. This speeds up the boot process - in a way, it preloads part of the applications - but it also makes hacking those apps difficult because part of the original code is already extracted somewhere else.
Deodexing is just a process of putting those pieces back into the original applications. It takes a while to extract those parts and build the .dex cache (aka Dalvik cache), but only because the relevant parts aren't in an easy-to-access place for the system. The advantage of this is that an app can be modified effectively and the developer doesn't have to worry about conflicts from the separate odex part of the code.
So, short version: "Deodexed" ROMs have all their apps put back together. If an app can be themed, for example, a deodexed version of that app will not get messed up when the modified .apk tries to mesh with the odex of the original un-modified .apk. Because it's not there.
If you want an aftermarket theme, you need a deodexed ROM. I'm not sure if deodexing can be done to individual apps within a non-deodexed ROM.
From the Android Developers Blog:
zipalign is an archive alignment tool 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. Specifically, it causes all uncompressed data within the .apk, such as images or raw files, to be aligned on 4-byte boundaries. This allows all portions to be accessed directly with mmap() even if they contain binary data with alignment restrictions. The benefit is a reduction in the amount of RAM consumed when running the application.