[HELP] Deodex for Android .. good or bad ? - Android Q&A, Help & Troubleshooting

Almost every custom ROM we see is deodexed .. claiming that it has better compability for theming . and also makes ROM faster
This is interesting because I saw some developers not recommending deodexing on Nougat and newer android versions, their reason is
On LP and MM, there is no significant difference between the two (odex/deodex) in terms of speed and functionality
On Nougat, there is a significant difference..
On MM and LP, ART compiles the apps ahead of time on first boot, therefore apps are theoretically odexed once the ROM has booted
On Nougat, Android boots without compiling the apps and instead compiles apps in the background during times of low load/idle. THIS SIGNIFICANTLY AFFECTS PERFORMANCE AND BATTERY LIFE*
Click to expand...
Click to collapse
I'd love to hear from experts about this

I'm hardly an expert, and I am aware that I'm responding to a 4 month old post, but this is what I understand regarding deodexing and the phones performance:
A deodexed rom is one where all the APK and JAR files in the /system partition have their respective classes.dex files inside them. An odexed rom has those files in separate files, outside the main APK/JAR. These separate files used to have the extension "*.odex" but now can have "*.oat" or "*.vdex" instead.
Modding an odexed app is annoying as, if you want to change any of the information in the classes, you have to decompile and recompile both files. Since ART came along, there are some framework files that you can't mod at all without having to mod others at the same time. So a deodexed rom makes things a lot easier. One file, one decompile, one recompile, done.
Android processes the classes in the system partition only when the device boots for the first time (or if the relevant cache has been wiped). A deodexed rom takes longer to boot at this stage as it's slower for Android to extract the DEX files and process them. Processing an 'Optimised DEX' file is faster and more efficient.
Once the device has booted though, you shouldn't notice any performance difference from what I understand. All the apps that are running when the device is on (framework-res.apk, SystemUI.apk, etc) have already been processed. The device can't start until they have.
The apps you choose to start, like a game or music player, won't be affected by the deodex/odex nature of the rom.
Again, this is only how I understand it. I'm not a developer and I don't mind being proven wrong. But I don't see how a device can boot without processing the system apps. It has to process the classes information to know what those apps do, and those apps do what they do as soon as the device boots.

Related

[Q] Can't a newbie like me understand anything about Android on smartphones?

I have read a few posts in this section, but it is totally impossible for someone like me (new to smartphones, flashing and the rest) to understand anything. Would you please explain some of the terminologies used here? Some of them are: kernel, 3g, port, system.ext2, BT... and thousands more.
Thank you very much!
you don't really "need" to understand any of that.
all you need to do is to learn how to download files, learn how to extract the downloaded file, learn how to copy them to an sd card, and learn how to run a program inside windows mobile.
if you can do all that, you should be set!!!
just follow steps 1-6 (ignore step 1b - the part about system.ext2) - http://forum.xda-developers.com/showthread.php?t=951962
Well noted AkumaX. Thank you very much!
XDAndroid is a project to port Android onto older HTC phones.
There are two main parts of XDAndroid, which combine to form a complete port:
Kernel/drivers: You can find packages to run Android on old HTC phones from a variety of sources, but whatever package you use, all rely upon the kernels/drivers created by the XDAndroid team to enable the basic hardware.
Android system: The Android system forms all of the parts of the phone's interface that you can directly interact with. Once the kernel/drivers have setup the hardware, you can add on an Android system port of your choice to form a complete build. Many system ports are available, both in terms of different versions (2.1 Eclair, 2.2 Froyo, 2.3 Gingerbread, etc.) and different starting points in the case of ports written by those outside of XDAndroid.
XDAndroid releases an "official" system port you can use, which is directly ported over by the XDAndroid team from the Android Open Source Project, and is very close to stock. Many of the alternative builds you come across are modifications of the XDAndroid system, containing customizations that deviate farther from stock Android, while others have different starting points altogether, and are ports of the ROMs found on official shipping devices that have already been customized (but still use the same basic kernel/drivers found here).
Android is a framework that runs on top of Linux. In order to get Android running on our devices, first we must get Linux running on the hardware with all drivers implemented, and then, we hook Android into these drivers. Thus, broadly viewed, the XDAndroid project is divided into two parts: the kernel/drivers and the Android port.
When you look at the files in your Android directory, you'll probably see something like the following:
zImage: The Linux kernel and drivers.
modules-###: Additional drivers for the kernel. Your system will load without this, but things like wifi may not work, or you may encounter instability.
initrd.gz: Used in the Linux boot process.
system.ext2: Most of the Android framework.
rootfs.img: Additional parts of the Android framework that are customized for our devices.
data.img: This file contains what would be your internal memory on a real Android device. Whenever you install a program it goes in to here. A new empty one will be automatically created if you don't have one.
haret.exe: Reboots you from Windows into XDAndroid.
startup.txt: Commands passed to XDAndroid on bootup that are customized by the user.
ts-calibration: Contains calibration information for the touch screen. If you don't have this file, you will be prompted to calibrate your screen on startup.
AndroidApps: A folder where if you copy any apks into it, they will be automatically installed on bootup.
manekineko said:
XDAndroid is a project to port Android onto older HTC phones.
-------.
Click to expand...
Click to collapse
Good explanation manekineko!...I believe this is what op was looking for.
there is light at the end of the tunnel, it wont take much longer if the devs keep up this good work, until there can be made stable and good builds with good battery life etc. when the time is there i will create an complete noob friendly installation guide (with pics and maybe even an vid).
I'm currently trying to figure out which one to install!
manekineko said:
XDAndroid is a project to port Android onto older HTC phones.
There are two main parts of XDAndroid, which combine to form a complete port:
Kernel/drivers: You can find packages to run Android on old HTC phones from a variety of sources, but whatever package you use, all rely upon the kernels/drivers created by the XDAndroid team to enable the basic hardware.
Android system: The Android system forms all of the parts of the phone's interface that you can directly interact with. Once the kernel/drivers have setup the hardware, you can add on an Android system port of your choice to form a complete build. Many system ports are available, both in terms of different versions (2.1 Eclair, 2.2 Froyo, 2.3 Gingerbread, etc.) and different starting points in the case of ports written by those outside of XDAndroid.
XDAndroid releases an "official" system port you can use, which is directly ported over by the XDAndroid team from the Android Open Source Project, and is very close to stock. Many of the alternative builds you come across are modifications of the XDAndroid system, containing customizations that deviate farther from stock Android, while others have different starting points altogether, and are ports of the ROMs found on official shipping devices that have already been customized (but still use the same basic kernel/drivers found here).
Android is a framework that runs on top of Linux. In order to get Android running on our devices, first we must get Linux running on the hardware with all drivers implemented, and then, we hook Android into these drivers. Thus, broadly viewed, the XDAndroid project is divided into two parts: the kernel/drivers and the Android port.
When you look at the files in your Android directory, you'll probably see something like the following:
zImage: The Linux kernel and drivers.
modules-###: Additional drivers for the kernel. Your system will load without this, but things like wifi may not work, or you may encounter instability.
initrd.gz: Used in the Linux boot process.
system.ext2: Most of the Android framework.
rootfs.img: Additional parts of the Android framework that are customized for our devices.
data.img: This file contains what would be your internal memory on a real Android device. Whenever you install a program it goes in to here. A new empty one will be automatically created if you don't have one.
haret.exe: Reboots you from Windows into XDAndroid.
startup.txt: Commands passed to XDAndroid on bootup that are customized by the user.
ts-calibration: Contains calibration information for the touch screen. If you don't have this file, you will be prompted to calibrate your screen on startup.
AndroidApps: A folder where if you copy any apks into it, they will be automatically installed on bootup.
Click to expand...
Click to collapse
Thank you so much for your explanations, manekineko. I believe that I am now ready to cruise through all the threads of this section without fear.
shatred said:
there is light at the end of the tunnel, it wont take much longer if the devs keep up this good work, until there can be made stable and good builds with good battery life etc. when the time is there i will create an complete noob friendly installation guide (with pics and maybe even an vid).
Click to expand...
Click to collapse
shatred, I am eagerly waiting for two things: (i) for the developers to release the perfect Android builds (my sincere encouragements to them by the way!!!) and (ii) for your installation guide.
gueyenono said:
I'm currently trying to figure out which one to install!
Click to expand...
Click to collapse
tell me your phone type, so an rhod-100? 200? 300? etc.
and tell me what you prefer more, an good battery life and an stable running system without camera support OR less stable system, bad battery life but with camera support.
Tell me and i will help you
shatred said:
tell me your phone type, so an rhod-100? 200? 300? etc.
and tell me what you prefer more, an good battery life and an stable running system without camera support OR less stable system, bad battery life but with camera support.
Tell me and i will help you
Click to expand...
Click to collapse
Uhm... You no longer have to choose. WisTilt2 pulled the latest commits from GIT into his test kernel.
arrrghhh said:
Uhm... You no longer have to choose. WisTilt2 pulled the latest commits from GIT into his test kernel.
Click to expand...
Click to collapse
yeah but if you activate the camera libs the phone wont go into deep sleep mode right? or is that fixed already?
shatred said:
yeah but if you activate the camera libs the phone wont go into deep sleep mode right? or is that fixed already?
Click to expand...
Click to collapse
Seems I was wrong about that. It was the other way around, if the libs are disabled the phone won't sleep.
However, with FRX05 there's no need for the libs. FRX05 + GIT kernel or WisTilt2's newest kernel is all you need for cam.
arrrghhh said:
Seems I was wrong about that. It was the other way around, if the libs are disabled the phone won't sleep.
However, with FRX05 there's no need for the libs. FRX05 + GIT kernel or WisTilt2's newest kernel is all you need for cam.
Click to expand...
Click to collapse
hmm yeah about that, i tried frx05 with wistilt2 latest kernels but it doesnt work for me, i think its an problem with my user conf... can you perhaps send me your user conf from frx05?
shatred said:
hmm yeah about that, i tried frx05 with wistilt2 latest kernels but it doesnt work for me, i think its an problem with my user conf... can you perhaps send me your user conf from frx05?
Click to expand...
Click to collapse
Same for FRX04... It's in my bundle.
If you remove all of the ln -s and bind mounts, should work just fine...

[Q] Parallel File Systems / ROM hacks

I had an odd thought. A lot of us like to test out other ROMs, but NANDROID backups and restores result in significant downtime. I'm curious if it would be possible to nest a fully installed ROM inside a subdirectory of the current running one and then swap them out in Recovery by rewriting the pertinent directory paths.
Obviously, there would be a requirement that both ROMs be compatible with the file system in question (Ext4 , etc.)
I mention all this because I would like to be able to quickly boot into Cyanogen 7 every now and then for the bluetooth stack and some of the other features here and there, but my daily driver is Bionix.
Obviously, a nice chunk of space would be "wasted" having duplicate copies of lots of files for apps and such (in addition to the space used having a second ROM) but I think the Galaxy S series NAND space is sufficient to try something like this.
Holy crap that's an amazing idea!!!
Theres already a way to do this its called dual booting and uses your internal memory.
Complicated though.
Are there any guides?
Yes, their in the android section (lol)
http://forum.xda-developers.com/showthread.php?t=847423
work in progress.....close to alpha release
Aww I thought it could already be readily available .
Nice though can't wait .
edit nevermind

Rooting

Do Not Post Question in General Post in Q&A CLOSED
I'm not super educated, but I'm pretty sure I can explain the fundamentals of it (correct me if I'm wrong anyone)...
The Android operating systems runs ontop of a linux kernel... and just like any other linux distribution, there is a particular set of low level system files that you, the user, by default, don't have access too. This is to prevent you from breaking anything, as well as to prevent malicious software/intruders to compromise the security of your file system.
These same low level system files, however, are useful for many things. In order to make changes to a lot of things (overclock your processor, tweak speed and battery life, sometimes sideload applications outside the market; although most devices let you do this without rooting now, and in most cases install a non-stock system image).
This system image is known as a ROM; a rom can be pulled from another device and then modified to work on your own, or in some cases can be an original release from Google (Known as an AOSP) which is then 'cooked' by a developer to work on your device.
If you're familiar with reinstalling or installing Windows, it's a pretty easy concept. Once a device is rooted, a custom recovery can be flashed to the device. This custom recovery allows you to flash over your stock system image with a new ROM.
Rooting is basically taking control over your device for what can be installed, deleted, or altered.
Here is a link to give you much more info on rooting:
http://m.androidcentral.com/what-rooting

[Q] Cooking ROMs... I still don't get it

Hello,
I'm willing to try and build a custom rom, but I've been diving through the site for a few days and I still don't get it. I believe I do have the required background to do this: programming, linux, etc. and I have wide experience as a phone user, etc. It's just that either I'm not reading what I need or the way I want it. The problem, I believe, is that all I find are guides telling me to install this and those tools and then open this and that and voila! you got your rom. But they're not explaining WHAT exactly goes into those roms, or what is expected to go there, what's the purpose of those contents, etc., and I can't really catch with that. I feel at a loss and hate wasting my time turning around for nothing.
1. I don't understand the difference between a flashable rom and one that is meant to be installed through recovery, although I can see they're different. Do they both models contain the same kind of data? Is there any restriction to what one model can contain over the other one? If so, how would I convert from one to the other? But please, don't tell me to use this or that tool. I just need the theory behind it. Something of sorts like: "You need to extract this or that from this tarball, then mount this image, then the directory tree there goes in that directory over the other model of rom"
2. update-binary: Okay I guess this is run when installing from recovery, and this takes care of installing the rom, right?wrong?. Is this a per-rom thing, per-device thing? generic? If it's per-rom, how to generate it? do I need to compile something? Is there any generic source code that can be used as a start?
3. Although I have a basic understanding of how the Linux directory tree works, I know Android works on top of a heavily modified Linux. So can you explain briefly how the directory tree works? For instance, I believe /data/data is where Android apps install to, in /system/bin or xbin I can find busybox binaries/symlinks if present. /dev and /proc look the same as in Linux. I don't know about /sys. Also how are both rom models deployed to this tree? What is basically being copied?
4. If I were to compile a kernel, where do I find the Android kernel sources? or is it just a generic Linux kernel? where can i get a basic config for the device? Last time I checked my device hadn't /proc/config.gz but maybe I could get it from another rom with it enabled or something. What toolchain and where to get it? Oh and if you know of a native arm version of gcc or whatsnot, I'd prefer that. Setting up IDEs or toolchains is a nightmare. I don't like crosscompiling. But crosscompiling or not, a directory with all needed binaries without needing to set up system variables nor other stuff, would be amazing.
I surely have a lot more questions that I can't get from the back of my mind now, and I'll have yet more as you explain. But the point of my questions was mainly trying to explain the degree of the loss I'm at, so you can assist me better.
If it looks like a foolish petition, well, that's because I'm quite stubborn and can't catch things that don't go my way. I really need to understand the basics before I can move into actually doing something. I want to build a rom for the right reasons(to me). It's not just about packing a set of apps or themes with it, but about learning and doing other stuff like trying to fix things that are not supposed to work for the device in that Android version, etc.
If you can't help, congrats for reading through here anyways But any help is greatly appreciated :good:
oxiroxt said:
Hello,
I'm willing to try and build a custom rom, but I've been diving through the site for a few days and I still don't get it. I believe I do have the required background to do this: programming, linux, etc. and I have wide experience as a phone user, etc. It's just that either I'm not reading what I need or the way I want it. The problem, I believe, is that all I find are guides telling me to install this and those tools and then open this and that and voila! you got your rom. But they're not explaining WHAT exactly goes into those roms, or what is expected to go there, what's the purpose of those contents, etc., and I can't really catch with that. I feel at a loss and hate wasting my time turning around for nothing.
1. I don't understand the difference between a flashable rom and one that is meant to be installed through recovery, although I can see they're different. Do they both models contain the same kind of data? Is there any restriction to what one model can contain over the other one? If so, how would I convert from one to the other? But please, don't tell me to use this or that tool. I just need the theory behind it. Something of sorts like: "You need to extract this or that from this tarball, then mount this image, then the directory tree there goes in that directory over the other model of rom"
2. update-binary: Okay I guess this is run when installing from recovery, and this takes care of installing the rom, right?wrong?. Is this a per-rom thing, per-device thing? generic? If it's per-rom, how to generate it? do I need to compile something? Is there any generic source code that can be used as a start?
3. Although I have a basic understanding of how the Linux directory tree works, I know Android works on top of a heavily modified Linux. So can you explain briefly how the directory tree works? For instance, I believe /data/data is where Android apps install to, in /system/bin or xbin I can find busybox binaries/symlinks if present. /dev and /proc look the same as in Linux. I don't know about /sys. Also how are both rom models deployed to this tree? What is basically being copied?
4. If I were to compile a kernel, where do I find the Android kernel sources? or is it just a generic Linux kernel? where can i get a basic config for the device? Last time I checked my device hadn't /proc/config.gz but maybe I could get it from another rom with it enabled or something. What toolchain and where to get it? Oh and if you know of a native arm version of gcc or whatsnot, I'd prefer that. Setting up IDEs or toolchains is a nightmare. I don't like crosscompiling. But crosscompiling or not, a directory with all needed binaries without needing to set up system variables nor other stuff, would be amazing.
I surely have a lot more questions that I can't get from the back of my mind now, and I'll have yet more as you explain. But the point of my questions was mainly trying to explain the degree of the loss I'm at, so you can assist me better.
If it looks like a foolish petition, well, that's because I'm quite stubborn and can't catch things that don't go my way. I really need to understand the basics before I can move into actually doing something. I want to build a rom for the right reasons(to me). It's not just about packing a set of apps or themes with it, but about learning and doing other stuff like trying to fix things that are not supposed to work for the device in that Android version, etc.
If you can't help, congrats for reading through here anyways But any help is greatly appreciated :good:
Click to expand...
Click to collapse
I am not terribly knowledgeable about all of this, but I will take a crack at it. Others can feel free to correct me.
1. "Flashing" is usually done through the recovery from a zip with an update script inside. That script is in a language called "edify". Read more about Edify Here and Here.
The only other common way that I know of installing a ROM is through fastboot in the bootloader, but that is normally only used with official factory images. Also, I think Samsung ROMs are often flashed with a proprietary program called Odin.
2. I think that the update-binary is standard across all recent devices. I think it is just an interpreter for the Edify scripting language. Old versions of android used a somewhat different scripting language and required a different file. You can probably pull the binary out of another recent zip and use that. The main thing you have to worry about is the update script (instructions for what the zip does) and the folder structure of the zip.
3. I am not confident to explain much here, but the apps and their data are stored in different places. User apps are stored in /data/app with app data stored in /data/data, I think. System apps are installed in /system/app. There is more files stored on the "sdcard" partition which can be internal or external, depending on the device.
4. Kernel sources are usually provided in the source code from whatever repo you are using. Different ROMs use different bases. Here is some info about grabbing the AOSP kernel sources with git: http://source.android.com/source/building-kernels.html
Many of the more popular ROMS have specific build instructions on their individual github pages (Cyanogen, Paranoid Android, etc), so you might what to look at those, too. Also, depending on the individual devices, there might be proprietary binaries sourced from the device or hardware manufacturers for things like camera drivers, graphics chips, etc.
If you want a walk through of the basic build process google has a tutorial. The last time I checked there seemed to be some outdated info, but it might give you a general idea of the build process. http://source.android.com/source/initializing.html
Hopefully someone more knowledgeable can give you more info, but that is all I got
synesthete said:
I am not terribly knowledgeable about all of this, but I will take a crack at it. Others can feel free to correct me.
1. "Flashing" is usually done through the recovery from a zip with an update script inside. That script is in a language called "edify". Read more about Edify Here and Here.
The only other common way that I know of installing a ROM is through fastboot in the bootloader, but that is normally only used with official factory images. Also, I think Samsung ROMs are often flashed with a proprietary program called Odin.
2. I think that the update-binary is standard across all recent devices. I think it is just an interpreter for the Edify scripting language. Old versions of android used a somewhat different scripting language and required a different file. You can probably pull the binary out of another recent zip and use that. The main thing you have to worry about is the update script (instructions for what the zip does) and the folder structure of the zip.
3. I am not confident to explain much here, but the apps and their data are stored in different places. User apps are stored in /data/app with app data stored in /data/data, I think. System apps are installed in /system/app. There is more files stored on the "sdcard" partition which can be internal or external, depending on the device.
4. Kernel sources are usually provided in the source code from whatever repo you are using. Different ROMs use different bases. Here is some info about grabbing the AOSP kernel sources with git: http://source.android.com/source/building-kernels.html
Many of the more popular ROMS have specific build instructions on their individual github pages (Cyanogen, Paranoid Android, etc), so you might what to look at those, too. Also, depending on the individual devices, there might be proprietary binaries sourced from the device or hardware manufacturers for things like camera drivers, graphics chips, etc.
If you want a walk through of the basic build process google has a tutorial. The last time I checked there seemed to be some outdated info, but it might give you a general idea of the build process. http://source.android.com/source/initializing.html
Hopefully someone more knowledgeable can give you more info, but that is all I got
Click to expand...
Click to collapse
OMG Finally some light! THANK YOU, THANK YOU, THANK YOU for all the info. I didn't get much right now, I'll need to read through your post a few times before I get it all, haha. I'll be sure to check the links too. Thank you!

G900TUVU1GPE1 Stock Odexed

I don't see anyone else posting here about it, so I just wanted to provide you guys with something to start out with.
First things first: Full Untouched ROM | Brokenly Debloated ROM
The Full Untouched ROM is exactly as it says, the ROM is extracted directly from the source and the permissions were set using the result of `ls -kR` and `ls -lnR` on an installed version of the ROM (see below for scripts). The Brokenly Debloated ROM does not have a functional Gallery (tbh, I probably just debloated too hard, and now I'm not sure which one was the essential one, something something camera3d.remote.nearby.Nearby??, but I don't use the Gallery, nor the Camera, so I removed them with TWRP's file manager), and I removed basically all the features that don't interfere with Wifi Calling (including Inprivate, Fingerprint, most of the Noto fonts removed (which support international fonts), removed all but 1 type of sound in each file, removed boot sound, removed even the Calculator) and then removed some of the things I don't like about stock. See below guides for more information. If you also happen to share my tastes and like it when there is almost nothing installed on your phone, then you should definitely try out the Broken Debloated ROM (it's actually very stable minus the Gallery), but if you want things like the Gallery or a Calculator or international fonts, find a different ROM, or take the Full one and debloat it.
Ok now, the good (and different) things about Marshmallow, and the things that I'm sure all you developers will like. (Note, this is for the Full ROM and should work with any Stock ROM, the Debloated version already has these applied).
Removing Knox info from Settings
Edit `/system/buildprop`, replace `ro.config.knox=v30` with `ro.config.knox=0`.
Yep, that's all, no patching, no fancy apktool baksmali magic requiring deodex.
Removing the S-Finder/QuickConnect Bar
Just delete `/system/etc/permissions/com.sec.feature.findo.xml`
Again, no patching.
Call Recording (this one isn't really new, it was more or less the same even in the past, but I included it anyways)
Add `<CscFeature_VoiceCall_ConfigRecording>RecordingAllowed</CscFeature_VoiceCall_ConfigRecording>` to `/system/csc/others.xml` anywhere between the `<FeatureSet> ... </FeatureSet>` tags.
I don't plan on searching for more, this is pretty comprehensive for my desires as it is, but if I happen to find them, I'll update this post.
Scripts
Note: this section is most likely unnecessary, since the updater-script already contains all of the below.
Links.hs opens "user.txt" and generates all the symlinks you need and outputs it to stdout.
Combine.hs opens "user.txt" and "sec.txt" and combines them so that the security contexts and permissions are in the same stream of text and outputs it to stdout.
Permissions.hs opens "allfiles.txt" and generates all the set_metadata requried arguments and outputs it to stdout.
If you want just the updater-script, it's also attached, all of the text from lines 24-123 were autogenerated by concatenating the outputs of Links.hs and Permissions.hs.
Also, as you can see, root is not included, but to be completely honest, the only thing I used to use root for was blocking ads. So I also including the Adblocker recovery-flashable zip I'm using (hosts file from here, updated as of 2016-05-24). It works even when SELinux is set to enforcing by properly updating the metadata (which it is in the ROMs posted in this thread).
thanks for syms
rmanne said:
I don't see anyone else posting here about it, so I just wanted to provide you guys with something to start out with.
First things first: Full Untouched ROM | Brokenly Debloated ROM
The Full Untouched ROM is exactly as it says, the ROM is extracted directly from the source and the permissions were set using the result of `ls -kR` and `ls -lnR` on an installed version of the ROM (see below for scripts). The Brokenly Debloated ROM does not have a functional Gallery (tbh, I probably just debloated too hard, and now I'm not sure which one was the essential one, something something camera3d.remote.nearby.Nearby??, but I don't use the Gallery, nor the Camera, so I removed them with TWRP's file manager), and I removed basically all the features that don't interfere with Wifi Calling (including Inprivate, Fingerprint, most of the Noto fonts removed (which support international fonts), removed all but 1 type of sound in each file, removed boot sound, removed even the Calculator) and then removed some of the things I don't like about stock. See below guides for more information. If you also happen to share my tastes and like it when there is almost nothing installed on your phone, then you should definitely try out the Broken Debloated ROM (it's actually very stable minus the Gallery), but if you want things like the Gallery or a Calculator or international fonts, find a different ROM, or take the Full one and debloat it.
Ok now, the good (and different) things about Marshmallow, and the things that I'm sure all you developers will like. (Note, this is for the Full ROM and should work with any Stock ROM, the Debloated version already has these applied).
Removing Knox info from Settings
Edit `/system/buildprop`, replace `ro.config.knox=v30` with `ro.config.knox=0`.
Yep, that's all, no patching, no fancy apktool baksmali magic requiring deodex.
Removing the S-Finder/QuickConnect Bar
Just delete `/system/etc/permissions/com.sec.feature.findo.xml`
Again, no patching.
Call Recording (this one isn't really new, it was more or less the same even in the past, but I included it anyways)
Add `<CscFeature_VoiceCall_ConfigRecording>RecordingAllowed</CscFeature_VoiceCall_ConfigRecording>` to `/system/csc/others.xml` anywhere between the `<FeatureSet> ... </FeatureSet>` tags.
I don't plan on searching for more, this is pretty comprehensive for my desires as it is, but if I happen to find them, I'll update this post.
Scripts
Note: this section is most likely unnecessary, since the updater-script already contains all of the below.
Links.hs opens "user.txt" and generates all the symlinks you need and outputs it to stdout.
Combine.hs opens "user.txt" and "sec.txt" and combines them so that the security contexts and permissions are in the same stream of text and outputs it to stdout.
Permissions.hs opens "allfiles.txt" and generates all the set_metadata requried arguments and outputs it to stdout.
If you want just the updater-script, it's also attached, all of the text from lines 24-123 were autogenerated by concatenating the outputs of Links.hs and Permissions.hs.
Also, as you can see, root is not included, but to be completely honest, the only thing I used to use root for was blocking ads. So I also including the Adblocker recovery-flashable zip I'm using (hosts file from here, updated as of 2016-05-24). It works even when SELinux is set to enforcing by properly updating the metadata (which it is in the ROMs posted in this thread).
Click to expand...
Click to collapse
Hi rmanne. Thanks for the debloated ROM. It runs very smoothly.
About the broken gallery, unfortunately I still need it. I looked into the exception thrown by the gallery, and looks like it is because some AllShare classes are missing in the classpath. However, I can't find out which file you removed contains these classes (none of the apks from /system/app/AllShare* works). Do you happen to know? Thanks!
rmanne said:
I don't see anyone else posting here about it, so I just wanted to provide you guys with something to start out with.
First things first: Full Untouched ROM | Brokenly Debloated ROM
The Full Untouched ROM is exactly as it says, the ROM is extracted directly from the source and the permissions were set using the result of `ls -kR` and `ls -lnR` on an installed version of the ROM (see below for scripts). The Brokenly Debloated ROM does not have a functional Gallery (tbh, I probably just debloated too hard, and now I'm not sure which one was the essential one, something something camera3d.remote.nearby.Nearby??, but I don't use the Gallery, nor the Camera, so I removed them with TWRP's file manager), and I removed basically all the features that don't interfere with Wifi Calling (including Inprivate, Fingerprint, most of the Noto fonts removed (which support international fonts), removed all but 1 type of sound in each file, removed boot sound, removed even the Calculator) and then removed some of the things I don't like about stock. See below guides for more information. If you also happen to share my tastes and like it when there is almost nothing installed on your phone, then you should definitely try out the Broken Debloated ROM (it's actually very stable minus the Gallery), but if you want things like the Gallery or a Calculator or international fonts, find a different ROM, or take the Full one and debloat it.
Ok now, the good (and different) things about Marshmallow, and the things that I'm sure all you developers will like. (Note, this is for the Full ROM and should work with any Stock ROM, the Debloated version already has these applied).
Removing Knox info from Settings
Edit `/system/buildprop`, replace `ro.config.knox=v30` with `ro.config.knox=0`.
Yep, that's all, no patching, no fancy apktool baksmali magic requiring deodex.
Removing the S-Finder/QuickConnect Bar
Just delete `/system/etc/permissions/com.sec.feature.findo.xml`
Again, no patching.
Call Recording (this one isn't really new, it was more or less the same even in the past, but I included it anyways)
Add `<CscFeature_VoiceCall_ConfigRecording>RecordingAllowed</CscFeature_VoiceCall_ConfigRecording>` to `/system/csc/others.xml` anywhere between the `<FeatureSet> ... </FeatureSet>` tags.
I don't plan on searching for more, this is pretty comprehensive for my desires as it is, but if I happen to find them, I'll update this post.
Scripts
Note: this section is most likely unnecessary, since the updater-script already contains all of the below.
Links.hs opens "user.txt" and generates all the symlinks you need and outputs it to stdout.
Combine.hs opens "user.txt" and "sec.txt" and combines them so that the security contexts and permissions are in the same stream of text and outputs it to stdout.
Permissions.hs opens "allfiles.txt" and generates all the set_metadata requried arguments and outputs it to stdout.
If you want just the updater-script, it's also attached, all of the text from lines 24-123 were autogenerated by concatenating the outputs of Links.hs and Permissions.hs.
Also, as you can see, root is not included, but to be completely honest, the only thing I used to use root for was blocking ads. So I also including the Adblocker recovery-flashable zip I'm using (hosts file from here, updated as of 2016-05-24). It works even when SELinux is set to enforcing by properly updating the metadata (which it is in the ROMs posted in this thread).
Click to expand...
Click to collapse
I'm coming from Android 6.0.1 via CyanogenMod 13.0. Do I need to also flash a modem and/or other key parts before this ROM will work?
Thanks!
Yes
Sent from my SM-G900T
I have a G900T3 (a strange beast) and am running a T3 bl and modem, with a rooted 5.1.1 G900T rom. I can't use a bl or modem for G900T; the phone refused to flash them.
I downloaded the MM firmware for the T3, but what next?
I can use Odin to flash all these packages, but in what order?
Will I need to flash TWRP again?
Will I lose root?
Can I re-root?
Sent from my SM-G900T using XDA-Developers mobile app
Can I flash this on my metro pcs phone SM-900T1? I will love to run marshmallows again.. I broke my s7 and this S5 is my back up.. Thank for any feed back...
Sent from my SM-G900T1 using XDA Free mobile app
Chris_Wilder said:
Can I flash this on my metro pcs phone SM-900T1? I will love to run marshmallows again.. I broke my s7 and this S5 is my back up.. Thank for any feed back...
Sent from my SM-G900T1 using XDA Free mobile app
Click to expand...
Click to collapse
You might want to try the official firmware instead.
http://www.sammobile.com/firmwares/database/SM-G900T1/
I were any way to add more languages in this firmware?

Categories

Resources