can I extract the contents of a mod.zip and take the .jar or .apk and copy and paste them into the framework dir of the working working folder? i tried copying a custom .apk file into the framework dir of the working folder and it went into a boot loop.
alucke
There could be several reasons for a boot loop. If I understand you correctly, you are working on a ROM using dsixda's kitchen, and you want to add an apk before flashing? Could you provide more information like what apk and what folder you are trying to add it to? I suspect it might have something to do with the signature of the apk. I'm not 100% sure but I believe that the system apks all need the same signature when flashing a new ROM.
alucke said:
can I extract the contents of a mod.zip and take the .jar or .apk and copy and paste them into the framework dir of the working working folder? i tried copying a custom .apk file into the framework dir of the working folder and it went into a boot loop.
alucke
Click to expand...
Click to collapse
If you are changing things within the framework you also need to edit the .xml files within the framework. The best way to learn is to take the stock rom and load it into a working folder. then take a custom rom that you can find all the differences to stock on when loaded on your phone and load that into the kitchen. Compare the stock roms working folder with the custom rom working folder and take note of all the differences and figure out how they were achieved. Dont just look at apk files. Look at the update script as well as the xml files in all the folders too. Repeat with another ROM and you will start to see how to change things around yourself.
Anybody know where to find the BOOTCLASSPATH order on this device? It's usually found in the "init.rc" file in the root directory of android, but it's nowhere to be found in that file on this device.
Is there some other way I can find the BOOTCLASSPATH other than finding it in one of the files?
Any help would be appreciated. Thanks!
Boostjunky said:
Anybody know where to find the BOOTCLASSPATH order on this device? It's usually found in the "init.rc" file in the root directory of android, but it's nowhere to be found in that file on this device.
Is there some other way I can find the BOOTCLASSPATH other than finding it in one of the files?
Any help would be appreciated. Thanks!
Click to expand...
Click to collapse
OK, found it, guys. It is located in the "init.environ.rc" file, rather than the standard which has been init.rc. Good to go, now. Thanks!
Boostjunky said:
OK, found it, guys. It is located in the "init.environ.rc" file, rather than the standard which has been init.rc. Good to go, now. Thanks!
Click to expand...
Click to collapse
Took me a while to find it too, you could also always do:
echo $BOOTCLASSPATH
in shell. For anyone looking for this. Here's the full path:
Code:
/system/framework/core.jar:/system/framework/conscrypt.jar:/system/framework/okhttp.jar:/system/framework/core-junit.jar:/system/framework/bouncycastle.jar:/system/framework/ext.jar:/system/framework/framework.jar:/system/framework/framework2.jar:/system/framework/telephony-common.jar:/system/framework/voip-common.jar:/system/framework/mms-common.jar:/system/framework/android.policy.jar:/system/framework/services.jar:/system/framework/apache-xml.jar:/system/framework/webviewchromium.jar:/system/framework/com.lge.frameworks.jar:/system/framework/WfdCommon.jar:/system/framework/org.codeaurora.Performance.jar
And here it is without the /system/framework/ path if you want to use it for dex/odex
Code:
core.jar:conscrypt.jar:okhttp.jar:core-junit.jar:bouncycastle.jar:ext.jar:framework.jar:framework2.jar:telephony-common.jar:voip-common.jar:mms-common.jar:android.policy.jar:services.jar:apache-xml.jar:webviewchromium.jar:com.lge.frameworks.jar:WfdCommon.jar:org.codeaurora.Performance.jar
What are you working on Bootsjunky?
havanahjoe said:
Took me a while to find it too, you could also always do:
echo $BOOTCLASSPATH
in shell. For anyone looking for this. Here's the full path:
Code:
/system/framework/core.jar:/system/framework/conscrypt.jar:/system/framework/okhttp.jar:/system/framework/core-junit.jar:/system/framework/bouncycastle.jar:/system/framework/ext.jar:/system/framework/framework.jar:/system/framework/framework2.jar:/system/framework/telephony-common.jar:/system/framework/voip-common.jar:/system/framework/mms-common.jar:/system/framework/android.policy.jar:/system/framework/services.jar:/system/framework/apache-xml.jar:/system/framework/webviewchromium.jar:/system/framework/com.lge.frameworks.jar:/system/framework/WfdCommon.jar:/system/framework/org.codeaurora.Performance.jar
And here it is without the /system/framework/ path if you want to use it for dex/odex
Code:
core.jar:conscrypt.jar:okhttp.jar:core-junit.jar:bouncycastle.jar:ext.jar:framework.jar:framework2.jar:telephony-common.jar:voip-common.jar:mms-common.jar:android.policy.jar:services.jar:apache-xml.jar:webviewchromium.jar:com.lge.frameworks.jar:WfdCommon.jar:org.codeaurora.Performance.jar
What are you working on Bootsjunky?
Click to expand...
Click to collapse
Just working on odexing a deodexed rom for personal use.
Sent from my LG-D851 using Tapatalk
Well, this is turning out to be big ol' boat load of fail. I take it that Xposed framework has some compatibility issues with Odexed ROMs?
Boostjunky said:
Well, this is turning out to be big ol' boat load of fail. I take it that Xposed framework has some compatibility issues with Odexed ROMs?
Click to expand...
Click to collapse
I have Xposed running on my stock ROM, which is odexed.
May I ask why you are odexing a deodexed ROM? Since there is only one G3 deodexed ROM I know of, why are you starting with ZoneROM and not from stock?
I have modified TetherNetwork.smali in the services.jar file of my stock rom and was able to get it odexed again after modifying.
No particular reason, other than that I just happened to have it flashed and setup on my device how I like everything. I just figured I'd top it off by odexing the ROM to slim down the footprint of the filesystem (I would be removing the classes.dex files after finishing the odex process).
I may just go ahead and jump back to a completely stock base and go from there.
Sent from my LG-D851 using Tapatalk
Boostjunky said:
No particular reason, other than that I just happened to have it flashed and setup on my device how I like everything. I just figured I'd top it off by odexing the ROM to slim down the footprint of the filesystem (I would be removing the classes.dex files after finishing the odex process).
I may just go ahead and jump back to a completely stock base and go from there.
Sent from my LG-D851 using Tapatalk
Click to expand...
Click to collapse
Oh I see. I have never done odexing or deodexing before. Is it possible to automate it and get all the dex files odexed? What problem did you run into? I had some issues getting my file deodexed but eventually got it to work. I missed a few things along the way, so maybe I can help?
I'm so used to setting up new ROMs that I don't think twice before jumping to another one. I have that sh*t down.
I also like the flashable blue theme he has for his ROM, and while I am capable of performing the same type of theming on the stock system files, I just don't have enough spare time to do it all.
Sent from my LG-D851 using Tapatalk
Boostjunky said:
I also like the flashable blue theme he has for his ROM, and while I am capable of performing the same type of theming on the stock system files, I just don't have enough spare time to do it all.
Sent from my LG-D851 using Tapatalk
Click to expand...
Click to collapse
Doesn't the theme need the files to be deodexed to work? How much more space do the deodexed files take compared to stock? I've been thinking of trying the other ROM, but like yourself, everything is working the way I like it for now, and there aren't that many benefits to the ROM yet (for me at least). I'll still check it out, and I'm sure it will get more features, or someone else will come up with a different take on the stock ROM.
I quickly threw together an odexing script that takes care of all the core files from the BOOTCLASSPATH first, then it odexes the remaining files in the framework folder.
Perhaps I'll have to sift through the script again and check that I didn't make any spelling errors.
Sent from my LG-D851 using Tapatalk
Most color scheme theming is done via .png and .xml edits, which are not found in the classes.dex files, but rather, in the "res" archive of the apk.
Sent from my LG-D851 using Tapatalk
The savings in space on the filesystem varies depending on the number of apps and whether the ROM is "Properly" odexed or not. If it's not properly odexed, the filesystem will end up even larger than a DeOdexed filesystem.
In a DeOdexed ROM, for every APK or JAR file, there is a classes.dex file within that APK/JAR archive. From this classes.dex file, the Dalvik Virtual Machine decompiles and stores an extracted/optimized classes.dex file known as the "dalvik-cache". So, in short, you end up with 2 dex files for every apk and jar package. 1 that is zipped into the apk/jar, and 1 that is extracted into the dalvik-cache directory.
In an Odexed ROM, for every APK or JAR file, there is a .odex file within the same folder that the APK/JAR is located. However the "classes.dex" file we spoke of earlier is no longer found inside a "properly" odexed apk or jar package. Where did it go? Well, it is the .odex file. It has simply just been pre-extracted, decompiled, and optimized for the system to use. And all without having to store it in the dalvik-cache directory. So, in short, you only end up with a single dex file (in this case, .odex) for each apk/jar package.
So, that's where you see the filesystem space savings.
The initial ROM size of an Odexed ROM is larger than a DeOdexed ROM (because the classes.dex files are zipped/compressed within the apk/jar package, whereas .odex files are not zipped/compressed).
But, after a DeOdexed ROM has initially booted up (I'm sure you've seen the message upon boot-up after clearing dalvik-cache that says "Android is upgrading x of xxx files), the resulting filesystem size is quite a bit larger since it now essentially has 2 copies of each classes.dex file from each apk/jar package (one compressed, the other decompressed).
Now, I said something about a "properly" odexed ROM. There are instances where a person will Odex their ROM, but won't pull the classes.dex file out of the apk/jar package after it's been odexed. This results in each apk/jar file potentially having 3 copies of the classes.dex file. 1 located within the apk/jar package (compressed), 1 located in the same folder as the apk/jar package (decompressed .odex file), and 1 in the dalvik-cache directory (again, decompressed as a classes.dex file).
Whew. That was a long explanation, but hopefully it gets the point across.
One thing I'm curious about is if ART will work with a "properly" Odexed filesystem. The reason I question it is because LG's filesystem would NOT be considered "properly" odexed since each apk/jar package has not only a .odex file, but also has a classes.dex file located within the package. So I have to wonder if ART uses the classes.dex file much like the Dalvik Virtual Machine, and that it won't convert a .odex file to an .oat file.
Just to update:
I found the issue via pulling a logcat during boot-up (or bootloop, rather). The issue was that I had attempted to Odex the framework file "com.qcom.bluetooth.jar" which just happens to NOT have a classes.dex file inside of it. Even though it didn't have a classes.dex file, the script still generated a false .odex file for that package, and thus during boot-up, the phone was not digging the file that made no sense.
Got her all Odexed in the framework, and am just about finished with odexing the /system/app/ and /system/priv-app/ apks. So far, so good.
I'll see if I can't get a filesystem size comparison after I'm finished with everything.
Results are in. The amount of space saved by Odexing the ROM I'm using ended up being 103.53 MB. Not as much as I imagined it would cut down (keep in mind, all the space savings is in the /data partition. The /system partition ends up using more space than the deodexed version of the ROM).
The sizes look like this.
Deodexed system size: 1.34 GB
Deodexed data size: 1.83 GB
Odexed system size: 1.53 GB
Odexed data size: 1.55 GB
Edit: I also tried enabling ART, and, as I expected, it doesn't work.
Hey dudes,
I have startetd to unpack the System image of the Pixel. But the rom of the Pixel is completely different from the normal Roms. (I have downloaded the latest from Googel Dev)
In normal system images are a lot of folders like App, bin, etc, fonts... But in the Pixel's System Image are only four folders and one image. The folders are App, lost+found, preloads and priv-app. The image is "system-other-odex-marker".
In the app folder are a lot of folders witch you have expercted. But if you open them are there only ".odex" and no apk's. Lost+found is empty, preloads has some cool images and a retail demo apk and in the priv-app the same as in the app folder. The image has 0KB and none ending.
My question: What is this for a system? It makes me simply impossible to port this rom! :crying:
Thanks
Chris
Hey dudes,
I have startetd to unpack the System image of the Pixel to Port it for Nexus. But the rom of the Pixel is completely different from the normal Roms. (I have downloaded the latest from Googel Dev)
In normal system images are a lot of folders like App, bin, etc, fonts... But in the Pixel's System Image are only four folders and one image. The folders are App, lost+found, preloads and priv-app. The image is "system-other-odex-marker".
In the app folder are a lot of folders witch you have expercted. But if you open them are there only ".odex" and no apk's. Lost+found is empty, preloads has some cool images and a retail demo apk and in the priv-app the same as in the app folder. The image has 0KB and none ending.
My question: What is this for a system? How can I fix my Problem? It makes me simply impossible to port this rom! :crying:
Thanks
Chris
Hey everyone, I have a quite strange question.
In the /system/app folder, some Google apps do not have a ./lib folder. See the screenshot! Chrome lacks ./lib folder but still works fine without any update. (so it uses the original Chrome.apk)
If I replace this Chrome.apk with the latest one, and chmod 644 as usual, Chrome won't work, unless I extract the /lib folder in the .apk file.
Quite strange, right? We all know apps that include libs require ./lib folder and its .so files to run.
Anyone who can explain this please?
My goal is to merge some updated apps into /system. But the partition is so small that I don't want to extract the libs.
TEEEEEEEEED said:
Hey everyone, I have a quite strange question.
In the /system/app folder, some Google apps do not have a ./lib folder. See the screenshot! Chrome lacks ./lib folder but still works fine without any update. (so it uses the original Chrome.apk)
If I replace this Chrome.apk with the latest one, and chmod 644 as usual, Chrome won't work, unless I extract the /lib folder in the .apk file.
Quite strange, right? We all know apps that include libs require ./lib folder and its .so files to run.
Anyone who can explain this please?
My goal is to merge some updated apps into /system. But the partition is so small that I don't want to extract the libs.
Click to expand...
Click to collapse
Not all apps in /system/app folder have lib folders. Only a couple of mine do.
Edit: I may have misunderstood your question. Just let me know
shagbag913 said:
Not all apps in /system/app folder have lib folders. Only a couple of mine do.
Edit: I may have misunderstood your question. Just let me know
Click to expand...
Click to collapse
Yes, but YouTube has lib. There should be a /system/app/YouTube/lib folder.
Oh do anyone notice the system_other.img in the full factory image? It is smaller than system.img and maybe flashed into system_b. I will extract the image and see if it contains lib.
However I can't see system_b mounted... Boot slot is a...