Related
I wanted to get some insight, direction and perhaps guidance on how to take the existing Deodexed ED2 ROM and get inside and make some edits, remove bloatware, replace Touchwiz with a different launcher etc. I am not looking to build a full blown custom ROM, I am just looking to edit a stock (yet deodexed) ROM to meet my needs.
Any help would be greatly appreciated so I can learn more about this process.
There are two ways you can do it. First way, that is usually a little easier to work with, is to extract the zip file, make the changes you want, and re-zip the whole thing. The other method is to just open the zip file (7zip or similar will make this a little easier) and add/delete stuff as you want. It eliminates the decompress/recompress part, but is a little harder to work with unless you know exactly what you want to do.
As far as figuring out what to remove and such, some files are named in a manner that they are easy to figure out (Mms.apk for example) and other files are not (Dlna.apk is AllShare). If you want to figure out what an APK file is, a good indication is sometimes opening it with say 7zip (they are essentially zip files) and extracting res/drawable-hdpi/icon.png and you can see what the icon is. Astro File Manager can also give you some info on the specific Apks, as can Titanium Backup I believe.
As for replacing things (like the launcher) it is as simple as taking one out and putting another in for most stuff. I will let you know that I had battery drain issues when I removed the stock TWLauncher, but I believe I know how to fix it then. A lot of stuff though, if you are replacing things, you'll want to do 1 or 2 things at a time and also be familiar with logcat as it is an invaluable tool when testing out ROM changes and problems.
Thanks imnuts, I will start to play with a zip file and go from there. As you mentioned the bloatware is in the system folder and not the data folder so perhaps I will just delete the bloat, and install GB Launcher on my phone and make it default so that TW is still there just not in use.
Hi,
a little late, but...
did you actually make this work? I'm trying the exact same thing, but my 4ext recovery always aborts the installation. Do I need to sign it or what is wrong?
Thanks a lot...
Please use the Q&A Forum for questions Thanks
Moving to Q&A
What exactly is the difference between odex and de-odex?
I see it a lot on the cleanrom thread?
While we're at it, what is fsync?
sai561 said:
What exactly is the difference between odex and de-odex?
I see it a lot on the cleanrom thread?
While we're at it, what is fsync?
Click to expand...
Click to collapse
Just a quick summary:
With Odex, files are smaller and optimized, so in theory your device is quicker if running Odex rom.
Deodex is slower, but needed for easy theaming (easier to modify).
fsync, disabled Database verification for data integrity, there for it's quicker, but since data is not verify, they may be courrpted if sudden reboot or something happened before they committed.
For more details just search for odex vs deodex.
Here are some more detailed explanations which I wrote somewhere else in the past:
Odex files contain pre-optimized code extracted from the system libs and apps, and live in the same directory as the jar or apk files inside /system, so they are part of the ROM. Odex files depend on each other, so the whole system, once odexed, cannot easily be modified.
With a de-odexed ROM, these odex files do not exist, instead the system apps are packaged like normal apps (with embedded classes.dex inside the apk which is the executable code), and on the first startup the system creates the pre-optimized code in the dalvik cache (/data/dalvik-cache).
A de-odexed ROM is easier to modify (because system apps are self-contained), is slower on the first start (because dexopt needs to run and build dalvik-cache), and uses more space in the /data partition (because the code is now duplicated - once inside the apk, and once in dalvik-cache).
fsync is a system call in Unix/Linux. "man fsync" says:
fsync() transfers ("flushes") all modified in-core data of (i.e., modified buffer cache pages for) the file referred to by the file descriptor fd to the disk device (or other permanent storage device) so that all changed information can be retrieved even after the system crashed or was rebooted. This includes writing through or flushing a disk cache if present. The call blocks until the device reports that the transfer has completed. It also flushes metadata information associated with the file (see stat(2)).
Click to expand...
Click to collapse
So it's something embedded in programs after a related set of write operations to ensure that all data has been written to the storage device. The bolded part is what makes it interesting for some to disable it - "The call blocks" means the calling program waits until it's finished, and this may create lag. The downside is that if the system crashes, the data on the storage devices may be inconsistent, and you may lose data.
fsync has nothing to do with database verification, only with ensuring that data is actually written to the storage device at a defined time in program execution.
What is an ODEX file?
In Android file system, applications come in packages with the extension .apk. These application packages, or APKs contain certain .odex files whose supposed function is to save space. These ‘odex’ files are actually collections of parts of an application that are optimized before booting. Doing so speeds up the boot process, as it preloads part of an application. On the other hand, it also makes hacking those applications difficult because a part of the coding has already been extracted to another location before execution.
What is an DEODEX file?
Deodexing is basically repackaging of these APKs in a certain way, such that they are reassembled into classes.dex files. By doing that, all pieces of an application package are put together back in one place, thus eliminating the worry of a modified APK conflicting with some separate odexed parts.
So, Deodexed ROMs (or APKs) have all their application packages put back together in one place, allowing for easy modification such as theming. Since no pieces of code are coming from any external location, custom ROMs or APKs are always deodexed to ensure integrity.
How this works?
For the majority noobs amongst us, Android OS uses a Java-based virtual machine called the Dalvik Virtual Machine. A deodexed or .dex file contains the cache used by this virtual machine (referred to as Dalvik-cache) for a program, and it is stored inside the APK. An .odex file, on the other hand, is an optimized version of this same .dex file that is stored next to the APK as opposed to inside it. Android applies this technique by default to all the system applications.
When an Android-based system is booting, the davlik cache for the Davlik VM is built using these .odex files, allowing the OS to learn in advance what applications will be loaded, and thus speeds up the booting process.
By deodexing these APKs, a developer actually puts the .odex files back inside their respective APK packages. Since all code is now contained within the APK itself, it becomes possible to modify any application package without conflicting with the operating system’s execution environment.
Advanteges & Disadvantages
The advantage of deodexing is in modification possibilities. This is most widely used in custom ROMs and themes. A developer building a custom ROM would almost always choose to deodex the ROM package first, since that would not only allow him to modify various APKs, but also leave room for post-install theming.
On the other hand, since the .odex files were supposed to quickly build the dalvik cache, removing them would mean longer initial boot times. However, this is true only for the first ever boot after deodexing, since the cache would still get built over time as applications are used. Longer boot times may only be seen again if the dalvik cache is wiped for some reason.
Note:Themes for android come in APKs too, and if you want to modify any of those, you should always choose a dedoexed custom ROM.
[Guide] What is Zipalign and how to make Apps zipaligned
What is Zipalign?
Zipalign is an archive alignment tool introduced first time with 1.6 Android SDK (Software Development Kit). It optimizes the way an Android application package (APK) is packaged. Doing so enables the Android operating system to interact with the application more efficiently, and hence has the potential to make the application and overall the whole system much faster. Execution time is minimized for zipaligned applications, resulting is lesser amount of RAM consumption when running the APK.
How does it exact work?
In an Android operating environment, data files stored in each application package are accessed by multiple processes, for example, the installer will read the data manifest to determine the associated permissions; the system server can read these resources for multiple reasons, like displaying notifications; the Home application, for example, will read resources to get the application’s name and icon. Since Android is based on a a true multi-tasking operating infrastructure, these files are continually and repeatedly accessed. Finally, but not least, the application itself reads the manifest data.
As Android is Linux-based, memory-mapping plays a key role in efficient handling of processes. Essentially, the optimal alignment for the Android OS’ resource-handling code is 4-byte boundaries. What this means is that, if APKs are memory-mapped to 4-byte boundaries, and aligned accordingly, the OS will not need to ‘read through’ the whole application package to get to the desired data manifest. Every system process will know in advance where to look for it’s desired resources, and hence will execute much smoother and faster.
Summing it up, zipaligning an APK results in all uncompressed data within the package to be aligned on 4-byte boundaries, allowing all portions to be accessed directly with the memory-map. RAM consumption is lowered while execution because the querying code doesn’t have to read through the entire application package.
Disavantages of unaligned APKs
Quite understandably, situation would be reserved for unaligned application packages. Resource reading would be slow and memory usage would be on the higher end of the spectrum. It would also depend on how many unaligned applications are present. For example, if less number of applications with an unaligned home application, you’d see slower application launch times. This is the best case scenario. For a worst case scenario, having a number of unaligned applications will result in the system repeatedly starting and killing processes, struggling with lags and huge battery drain.
How to make APKs zipaligned?
As mentioned earlier, the zipalign tool became a part of Android SDK from 1.6 onwards. It can be found under the ‘tools’ folder of the SDK. To use it, simply run the command:
zipalign [-f] [-v] <alignment> infile.apk outfile.apk
Click to expand...
Click to collapse
...where infile.apk is the source file, and outfile.apk is the output file.
You can also verify the alignment of an APK file using the following command:
zipalign -c -v <alignment> existing.apk
Click to expand...
Click to collapse
...where existing.apk can be any application package that you need to get verified. Also, the <alignment> tag in both the commands needs to be an integral value (otherwise the command will return invalid). This value, although can be any integer, MUST always be 4, which would provide 32-bit alignment. Any other value and it will effectively do nothing.
Finally, for the flags used in these commands,
-f - overwrites existing outfile.zip
-v - will give verbose output
-c - will confirm the alignment of a given file
Click to expand...
Click to collapse
CAUTION: Zipalign operation must only be performed after you have signed the APK file with your private key. If zipaligned before signing, the signing procedure will disturb the alignment. Same holds true for any other alteration, addition or removal to the APK file. Any change after running zipalign will undo the alignment.
Source: addictivetips
[GUIDE] How to Deodex Jelly Bean firmware (I9070) - credits must go to anantttt
[How-To] Re-Odex a Rom - credits must go to TearsDontFalls -this guide is for S3, but you have Google to find what you need ... if you really need.
[ODEX][SCRIPT/TOOL] Odexer Tool 1.2 (03-28-2014)(MM-dd-yyyy)
Update 08.10.2014
Click to expand...
Click to collapse
[SCRIPT TO ODEX] Universal Odex Script Version 6.3.1 (11-03-2013)
Credits & Thanks for this tool:
MatrixDJ96
Click to expand...
Click to collapse
I think you just must create 1 thread titled "About Android" or someting like that
BTW it is good to know that:thumbup::thumbup:
Sent from my GT-I9070 using xda app-developers app
This materials are not created by me, I just searched and read carefully over the WWW in an attempt to bring as much informations to our forum S. Advance.
Only this was my job, along with the desire to know the phone held.
In my opinion, one thread with all the information is difficult to manage, because of that i'm so reluctant in what concerns for easy finding by members.
Make a Guide on how to (Re)Odex a Deodexed ROM if possible...
Sent from my GT-I9070 using xda app-developers app
Flash stock ROM?
R_a_z_v_a_n said:
Flash stock ROM?
Click to expand...
Click to collapse
Hahahaha.. but I wasn't Joking.. people say that its always better Re-Odex a Deoxed app after editing it
Understand now. Let me do some research and read what to do in that sense ...
Sami Kabir said:
Make a Guide on how to (Re)Odex a Deodexed ROM if possible...
Click to expand...
Click to collapse
Make it very short then.
Odex Me
(Post useful? Hit the Thanks button etc.)
Odex and Deodex
Hi,
I am a beginner in the android world and i have been trying to understand the android terms in detail. but i am still confused over the ODEX and DEODEX terms. I read you post but it still needs some more explanation of few things mentioned below.
Where is the .ODEX file stored in case of an ODEXED Rom?
Does the Dalvik Cache builds up in case the ROM in Deodexed. If yes then from where it fetches the required information?
Your post says that boot speed is increased in case of both the ODEX & DEODEX ROM after the first Boot. Then what is the exact difference between the two ROMS?
Does Dalvik Cache & DalviK VM independent whether the ROM is ODEX or DEODEX?
Presently my phone is ODEX (Stock ROM), once i DEODEX the ROM can i still install .APK files from Google Play or any other source?
Is tools which makes an APK ODEX or DEODEX part of the android operating system or should we make an APK Odexed or Deodexed using a laptop?
Please help me with the above questions.
R_a_z_v_a_n said:
What is an ODEX file?
In Android file system, applications come in packages with the extension .apk. These application packages, or APKs contain certain .odex files whose supposed function is to save space. These ‘odex’ files are actually collections of parts of an application that are optimized before booting. Doing so speeds up the boot process, as it preloads part of an application. On the other hand, it also makes hacking those applications difficult because a part of the coding has already been extracted to another location before execution.
What is an DEODEX file?
Deodexing is basically repackaging of these APKs in a certain way, such that they are reassembled into classes.dex files. By doing that, all pieces of an application package are put together back in one place, thus eliminating the worry of a modified APK conflicting with some separate odexed parts.
So, Deodexed ROMs (or APKs) have all their application packages put back together in one place, allowing for easy modification such as theming. Since no pieces of code are coming from any external location, custom ROMs or APKs are always deodexed to ensure integrity.
How this works?
For the majority noobs amongst us, Android OS uses a Java-based virtual machine called the Dalvik Virtual Machine. A deodexed or .dex file contains the cache used by this virtual machine (referred to as Dalvik-cache) for a program, and it is stored inside the APK. An .odex file, on the other hand, is an optimized version of this same .dex file that is stored next to the APK as opposed to inside it. Android applies this technique by default to all the system applications.
When an Android-based system is booting, the davlik cache for the Davlik VM is built using these .odex files, allowing the OS to learn in advance what applications will be loaded, and thus speeds up the booting process.
By deodexing these APKs, a developer actually puts the .odex files back inside their respective APK packages. Since all code is now contained within the APK itself, it becomes possible to modify any application package without conflicting with the operating system’s execution environment.
Advanteges & Disadvantages
The advantage of deodexing is in modification possibilities. This is most widely used in custom ROMs and themes. A developer building a custom ROM would almost always choose to deodex the ROM package first, since that would not only allow him to modify various APKs, but also leave room for post-install theming.
On the other hand, since the .odex files were supposed to quickly build the dalvik cache, removing them would mean longer initial boot times. However, this is true only for the first ever boot after deodexing, since the cache would still get built over time as applications are used. Longer boot times may only be seen again if the dalvik cache is wiped for some reason.
Note:Themes for android come in APKs too, and if you want to modify any of those, you should always choose a dedoexed custom ROM.
Click to expand...
Click to collapse
fredrickaein said:
1.Where is the .ODEX file stored in case of an ODEXED Rom?
2.Does the Dalvik Cache builds up in case the ROM in Deodexed. If yes then from where it fetches the required information?
3.Your post says that boot speed is increased in case of both the ODEX & DEODEX ROM after the first Boot. Then what is the exact difference between the two ROMS?
4.Does Dalvik Cache & DalviK VM independent whether the ROM is ODEX or DEODEX?
5.Presently my phone is ODEX (Stock ROM), once i DEODEX the ROM can i still install .APK files from Google Play or any other source?
6.Is tools which makes an APK ODEX or DEODEX part of the android operating system or should we make an APK Odexed or Deodexed using a laptop?
Click to expand...
Click to collapse
Some answers, I numbered your questions to be more easily tracked
1. In your /system
2. Android's Dalvik goes through every apk's and extracts the dex file from it. It places the dex files in the cache folder - located at /data/dalvik-cache. This is the directory that gets cleared when you clear the dalvik cache in your custom recovery like CWM or TWRP.
3. The difference is that deodexed ROMs are lighter and allow modifications but odexed ROMs load faster. ROMs come with Zipalign at boot that make a deodexed ROM load as fast as an odexed ROM.
4. I dont know the answer of this ... sorry.
5. Of course you can, is no reason to worry about.
6. You need android-sdk installed in your computer/laptop, busybox on the phone, xUltimate and some knowledge about whole process.
Thanks a few more on odexed and deodexed ROM
Hi,
Many thanks for your prompt reply. But please bare with me as i am going to ask more questions
Firstly let me ask you some more queries related to the earlier questions
1 Which folder in my ROM. I have root access, so i would like to view the files.
2 got it. saw the directory where the delvik cache is stored, but in case of a deodexed rom does this happen? i mean does the system store the dalvik cache by going through the apk if the ROM is deodexed. in other words does dalvik cache exist for deodexed ROM?
3 why is the deodexed ROM lighter? is it because it stores the app info at one place?
4. actually the question is same as no 2 above, Will i see the delvik-cache folder anymore if i deodex my ROM? if no then does the zipalign provides necessary data for the dalvik VM?
5.Ok i understood this
6. the process you are talking about is how to deodex my ROM. So i guess once i try to deodex my ROM the process will convert all the odexed app in my phone to deodexed. and henceforth all the appliccation that i install will be installed as a deodexed app. am i right in my guess?
Now some more questions please
7. is the only difference between them is the fact that odexed rom stores the app in two places and deodexed rom stores as a single apk?
8. what exactly is the .ODEX dex file. Is it a full copy of the apk or only a part of the apk. i guess it is this .ODEX file that makes the odexed rom heavy while the deodexed rom doesnt contain a .ODEX file which makes it lighter
R_a_z_v_a_n said:
Some answers, I numbered your questions to be more easily tracked
1. In your /system
2. Android's Dalvik goes through every apk's and extracts the dex file from it. It places the dex files in the cache folder - located at /data/dalvik-cache. This is the directory that gets cleared when you clear the dalvik cache in your custom recovery like CWM or TWRP.
3. The difference is that deodexed ROMs are lighter and allow modifications but odexed ROMs load faster. ROMs come with Zipalign at boot that make a deodexed ROM load as fast as an odexed ROM.
4. I dont know the answer of this ... sorry.
5. Of course you can, is no reason to worry about.
6. You need android-sdk installed in your computer/laptop, busybox on the phone, xUltimate and some knowledge about whole process.
Click to expand...
Click to collapse
My friend,
You ask too many questions and I do not think going somewhere after you have the answers.
So, lets start with ...
1.There is two place: I tell you in system/root ... search for directors -> data/app or system/app
2 Of course. Because of this the first start of a deodexed ROM is slower.
3 ... is it because it stores the app info at one place? I dont know for sure, but is one of the explanation. Lighter can also mean that the apk can be modified by Themers much easier without any risk.
4. Yes will see the folder, i just tell where is located from my phone when i answered before. And i have my ROM deodexed and zipalign
5....
6. You are right.
7. Yes, and much easier to theme without risks
8. I guess is correct, dont know much about that
present hipirch
Dear Razvan,
Thanks for the help. I am very curious in nature, that why i bothered you so much.
Now please a last suggestion from you.
Shall i Deodex my Samsung Stock ROM? or go for already deodexed Pure Vanila or Jelly Bean LQB / SlimJB - Shaaan (Your Rom). please Suggest.
And also based on your experience, which Custom ROM you prefer for Galaxy S Advance (Just your Opinion )
R_a_z_v_a_n said:
My friend,
You ask too many questions and I do not think going somewhere after you have the answers.
So, lets start with ...
1.There is two place: I tell you in system/root ... search for directors -> data/app or system/app
2 Of course. Because of this the first start of a deodexed ROM is slower.
3 ... is it because it stores the app info at one place? I dont know for sure, but is one of the explanation. Lighter can also mean that the apk can be modified by Themers much easier without any risk.
4. Yes will see the folder, i just tell where is located from my phone when i answered before. And i have my ROM deodexed and zipalign
5....
6. You are right.
7. Yes, and much easier to theme without risks
8. I guess is correct, dont know much about that
Click to expand...
Click to collapse
Do not you worry I did not mind. :highfive:
You can put a deodexed ROM, but only if you want to apply some themes or customization, otherwise there is no reason to do so.
Frankly, in terms of what ROM to install, I can not give any advice, because besides his SlimJB Shaaan, i did not try any custom ROM, but i'm waiting, in silence , Cyanogen ROM stable and then i can make a choice.
Good luck
Yeah, I am also waiting for a stable 10.1 of cynogen. But how is the rom that you are using? How stable is it? I am also planing to try pure vanila till we have a stable release of cynogen. Anyways many thanks for the help.
R_a_z_v_a_n said:
Do not you worry I did not mind. :highfive:
You can put a deodexed ROM, but only if you want to apply some themes or customization, otherwise there is no reason to do so.
Frankly, in terms of what ROM to install, I can not give any advice, because besides his SlimJB Shaaan, i did not try any custom ROM, but i'm waiting, in silence , Cyanogen ROM stable and then i can make a choice.
Good luck
Click to expand...
Click to collapse
For the moment i'm using LQB Serbia, deodexed, zipaligned and debloated with CoCore 6.x kernel and i'm SOOO happy .... but we are OFF TOPIC here, thanks for understanding me.
Just a question. I am now on stock odex DXLSE with speedmod kernel. Can I flash on cwm the deodexed version of the same rom without wiping the data and without losing all of my files? Thanks.
JB? Rooted?
Its necessary...
Sent from my GT-I9070 using xda premium
Odex versus Deodex
As an Android newbie, what bothered me most was coming across terminology beyond my comprehension. Not coming from a Linux background it became hard to keep up with the oh-so-commonly-used words spread all across the development community. Likewise, since I didn’t understand the terms, consequently I was unable to determine is something was of any use to me or not. From what I have seen, this problem extends to many novice and even average users.
One commonly occurring word when playing with custom ROMs and firmware, and even themes is deodexed and odexed. Most users fail to understand what these terms actually imply, and while developers would boast again and again about their themes and ROMs being deodexed, the average user is left clueless as to what is going on.
What is an .odex file?
In Android file system, applications come in packages with the extension .apk. These application packages, or APKs contain certain .odex files whose supposed function is to save space. These ‘odex’ files are actually collections of parts of an application that are optimized before booting. Doing so speeds up the boot process, as it preloads part of an application. On the other hand, it also makes hacking those applications difficult because a part of the coding has already been extracted to another location before execution.
Then comes deodex!
Deodexing is basically repackaging of these APKs in a certain way, such that they are reassembled into classes.dex files. By doing that, all pieces of an application package are put together back in one place, thus eliminating the worry of a modified APK conflicting with some separate odexed parts.
In summary, Deodexed ROMs (or APKs) have all their application packages put back together in one place, allowing for easy modification such as theming. Since no pieces of code are coming from any external location, custom ROMs or APKs are always deodexed to ensure integrity.
How this works
For the more geeky amongst us, Android OS uses a Java-based virtual machine for running applications, called the Dalvik Virtual Machine. A deodexed, or .dex file contains the cache used by this virtual machine (referred to as Dalvik-cache) for a program, and it is stored inside the APK. An .odex file, on the other hand, is an optimized version of this same .dex file that is stored next to the APK as opposed to inside it. Android applies this technique by default to all the system applications.
Now, when an Android-based system is booting, the davlik cache for the Davlik VM is built using these .odex files, allowing the OS to learn in advance what applications will be loaded, and thus speeds up the booting process.
By deodexing these APKs, a developer actually puts the .odex files back inside their respective APK packages. Since all code is now contained within the APK itself, it becomes possible to modify any application package without conflicting with the operating system’s execution environment.
Advantages & Disadvantages
The advantage of deodexing is in modification possibilities. This is most widely used in custom ROMs and themes. A developer building a custom ROM would almost always choose to deodex the ROM package first, since that would not only allow him to modify various APKs, but also leave room for post-install theming.
On the other hand, since the .odex files were supposed to quickly build the dalvik cache, removing them would mean longer initial boot times. However, this is true only for the first ever boot after deodexing, since the cache would still get built over time as applications are used. Longer boot times may only be seen again if the dalvik cache is wiped for some reason.
For a casual user, the main implication is in theming possibilities. Themes for android come in APKs too, and if you want to modify any of those, you should always choose a dedoexed custom ROM.
Full credits to the source: addictivetips.com
Update: Here's a link to the Universal Odex Script made by MatrixDJ96
Thanks mate, You really saved my lot of time.:good:
Native7i said:
Thanks mate, You really saved my lot of time.:good:
Click to expand...
Click to collapse
You're welcome!
I really wanted to know about that, since people mention it a lot lately, thanks
Nice write up very proffesional this should be stickied for new users
Sent from my SCH-I500 using Tapatalk 2
Thanks!
Thanks! helped me alot! very informative.
The best explanation
If you want, you can share my universal odex script for all phone in your thread
Sent from my GT-I9100 using xda app-developers app
Thank you. As a newbie, I learned a lot from your explanations.
MatrixDJ96 said:
The best explanation
If you want, you can share my universal odex script for all phone in your thread
Sent from my GT-I9100 using xda app-developers app
Click to expand...
Click to collapse
Hey MatrixDJ96
I've added the link to your script.
Wow, this was a real lifesaver :victory: I finally can differentiate
:good:
nice write up
Thanks
Thanks, Really help a lot...
that was a really clear explanation - thanks!
Hi, I'm trying to modify /system/framework/framework-res.apk (on the stock Samsung Oreo ROM), more exactly config_locationProviderPackageNames in res/values/arrays.xml so that I can add org.microg.nlp as location provider. I've used the latest apktool (2.3.4) to unpack and repack the apk. I'm replacing it from TWRP and I checked that it has the same owner and rights. And after rebooting the device never finishes booting up (stuck at Samsung logo and blue led).
If I boot back to recovery and put back the original framework-res.apk the system boots fine.
What else do I need to do to make it accept the modified framework?
hey
Are you ONLY modifying the apk?
I would say there is a lot of things to check. It could be that the apk is being rejected by your handling of it. Compare both versions by 7zip lz4 without extracting. Try and use the best tools during the process.
Also more than likely you're conflicting with a service or permission that a perfect apk can't fix.
Have you tried a search in your ROM to see if any files might be associated with the result you want?
Stuff like...
com.android.location.provider.jar
com.android.location.provider.odex
com.android.location.provider.xml
Try doing all the work from your phone without any windows apps. FX explorer and symlink the apk.
Now that everything I said was probably wrong, someone else can tell you how. I'd try fx and symlink, though. It may just align the planets for you
I'm only modifying one XML resource file, but I don't know what else apktool is doing to the apk.
I'm replacing the original framework-res.apk from TWRP, by cat-ing the modified apk over the original, and I've double checked that the ownership and permissions are unchanged.
I guess I can try using another unpack/repack tool and see if it turns out any better, but I've been told that apktool is as good as it gets.
Perhaps it's because the ROM expects the apk to be signed with a certain key? I don't suppose that the key used by Samsung is available somewhere inside the ROM is it?
wirespot said:
I'm only modifying one XML resource file, but I don't know what else apktool is doing to the apk.
I'm replacing the original framework-res.apk from TWRP, by cat-ing the modified apk over the original, and I've double checked that the ownership and permissions are unchanged.
I guess I can try using another unpack/repack tool and see if it turns out any better, but I've been told that apktool is as good as it gets.
Perhaps it's because the ROM expects the apk to be signed with a certain key? I don't suppose that the key used by Samsung is available somewhere inside the ROM is it?
Click to expand...
Click to collapse
@wirespot - Did you ever solve the problem you described in this thread?
Not really. My last attempt was to use Runtime Resource Overlays (RROs) to override certain framework values in order to allow org.microg.nlp to run side by side with Google's service.
I will provide them below but it ultimately didn't work. The RRO apk was installed correctly, I could access the NLP settings in the system settings but the main app still could not detect or connect to the service and none of the apps that use location would work.
If anybody else wants to build or use the RRO apk I'm attaching the relevant files as well as the apk. Please note that the built apk only has "org.microg.nlp" as service in arrays.xml (but I provide an arrays.xml with all three services).
apktool.yml is provided as txt file because it wouldn't let me upload it otherwise, remove the .txt. It's used if you build the package with apktool. Remember that you'll also have to generate your own certificate and sign the package in order to install it.
Also some links that may help:
https://forum.xda-developers.com/t/guide-how-to-make-gsis-overlay-file-for-your-phone.3878974/
https://github.com/ReinhardStrauch/framework-res-overlay-sample
https://android.stackexchange.com/questions/110927/how-to-mount-system-rewritable-or-read-only-rw-ro
https://source.android.com/devices/architecture/rros#configuring-overlays
https://source.android.com/devices/automotive/hmi/car_ui/appendix
https://source.android.com/devices/automotive/hmi/car_ui/rro#step_6_dump_the_idmap
https://dzone.com/articles/customizing-android-devices-using-the-runtime-reso
https://dzone.com/articles/android-solution-install-parse-1
https://stackoverflow.com/questions...s-not-recognized-internal-or-external-command
https://github.com/lineageos4microg/android_prebuilts_prebuiltapks/issues/22
wirespot said:
I guess I can try using another unpack/repack tool and see if it turns out any better, but I've been told that apktool is as good as it gets.
Click to expand...
Click to collapse
For decompiling and building Android Oreo, I prefer version 2.3.1 of APKTool to other versions of APKTools.
wirespot said:
I'm only modifying one XML resource file, but I don't know what else apktool is doing to the apk.
...
Perhaps it's because the ROM expects the apk to be signed with a certain key? I don't suppose that the key used by Samsung is available somewhere inside the ROM is it?
Click to expand...
Click to collapse
wirespot said:
Hi, I'm trying to modify /system/framework/framework-res.apk (on the stock Samsung Oreo ROM), more exactly config_locationProviderPackageNames in res/values/arrays.xml so that I can add org.microg.nlp as location provider.
What else do I need to do to make it accept the modified framework?
Click to expand...
Click to collapse
I have not tried modifying framework-res.apk of a Samsung Android Oreo nor have I particularly tried the location services mod you are attempting (though I might get around to trying it someday) and do not know if it is valid to to accomplish what you want with it, but believe that the process should be similar to modding the file on LG Android Oreo. I shall try to guide you to how to prepare a framework-res.apk that is proper.
To answer your question about expecting a certain key. The answer to that is that that is usually the case. The signing scheme checks on system apps; however is usually not as thorough as non-system apps. framework-res.apk is also special in that it is not a running app and is instead used as a cache of system resources and system meta information. In the past, before Android Oreo, a rebuilt framework-res.apk may be made to work simply by including original signature files (META-INF) and corresponding AndroidManfest.xml file from the original framework-res.apk into the rebuilt fraemwork-res.apk file. The system would evaluate these files, and pass a check for valid platform signature. With Android Oreo, it appears that there is an additional check that was not present in the past; my best guess is that the system is checking for the V2 signing scheme signing block within the V2 Signing Scheme APK file structure. The check does not, however, thoroughly validate the signing block information.
Your mod seems rather simple and, given your previous posts, would only involve a modification to framework-res.apk "resources.arsc" member file (which contains the compiled "res/values/arrays.xml" file). If the rebuilt "resources.arsc" can be used to update ("Update" is an actual ZIP archive operation) the original framework-res.apk's member file, the updated framework-res.apk should work (and remained zip-aligned if originally zip-aligned), so long as the packed file size of the updated member file is less than or equal to the packed size of the original member file, plus up to 4 bytes depending on proximity to the next member file data if original framework-res.apk is zip-aligned as expected. If the packed modified member file(s) are larger, the original APK file structure would likely not be preserved, and a different method might have to be used. Also note that 7-Zip is not reasonable software to use for this, despite it being included with many tools on XDA to modify APK files; the software has had a history of rearranging unnecessarily zip file table entries when a change is made to an archive. Use a different tool that does not do this, such as WinRAR (I have tested version 5.61).
For normal apps, one may not copy over "resources.arsc" or resources from two different app builds and have things work correctly when the app runs; one would also need to make corresponding changes in the *.dex APK member files. framework-res.apk, not being an app the runs, has no corresponding *.dex files, and one need not worry about corrupting the relationship between the *.dex files and the resource files because none exists to corrupt.