Develop Bugs

[GUIDE] How to make an Odin ROM

How to make an Odin flashable ROM
This is just a small guide I want to share with anyone who's interested in the commands I personally use. Feel free to correct me or give better commands / instructions.
@Moderators:
If this thread is in the wrong section or already present at XDA, PM me.
This needs a UNIX compatible OS - like Linux or Mac OS X.
On Windows, you can use "Cygwin".
Click to expand...
Click to collapse
Use the dd (datadump) command to make the .rfs files
Of course you need to connect your phone via USB and have ADB prepared on your computer.
# Get Root access first
Code:
su
# Do this first to mount the /system R/W
(thanks to scheichuwe for the simplified command)
Code:
mount -o remount,rw /dev/block/stl9 /system
# Dump the needed data / partitions to your /sdcard
Code:
dd if=/dev/block/stl9 of=/sdcard/factoryfs.rfs bs=4096
dd if=/dev/block/stl11 of=/sdcard/cache.rfs bs=4096
dd if=/dev/block/bml7 of=/sdcard/zImage bs=4096
dd if=/dev/block/bml12 of=/sdcard/modem.bin bs=4096
# Make the tar ball
Code:
tar -H ustar -c factoryfs.rfs cache.rfs modem.bin zImage > darky.tar
# MD5 it for a security check
Code:
md5sum –t darky.tar >> darky.tar
# Rename the tar file
Code:
mv darky.tar darky.tar.md5
Optional:
Make your own pit file
The pit file is used to set the partition layout (Partition Information Table).
# Dump the pit
Code:
dd if=/dev/block/bml2 of=/sdcard/darky.pit bs=4096
I hope I could help you with that
- darkyy.

Nice
Yeah first

Oh and one more thing:
If someone is gonna rate this thread 1 star, please explain here why.

So this means I can make an Odin rom of my current installed config? Or am I missing something?
If you then flash your tar + pit, you have your kernel and rom restored? This would be an awesome way to backup a good config, no?

VenQWish said:
So this means I can make an Odin rom of my current installed config? Or am I missing something?
If you then flash your tar + pit, you have your kernel and rom restored? This would be an awesome way to backup a good config, no?
Click to expand...
Click to collapse
Exactly - these commands will dump the data directly from your current phone.
And yes, you'll have a 1 to 1 Backup.

That is actually VERY useful! I'm constantly switching between a modded Insanity and CM7, and constantly reverting to stock, flashing custom kernels and flashing nandroids is getting quite annoying now.
Don't have access to a linux machine now, I'll try this asap, thanks!

Wow, dasch mal nützlich ville dank^^
Neat. Thank you!

Quipeace said:
That is actually VERY useful! I'm constantly switching between a modded Insanity and CM7, and constantly reverting to stock, flashing custom kernels and flashing nandroids is getting quite annoying now.
Don't have access to a linux machine now, I'll try this asap, thanks!
Click to expand...
Click to collapse
Well you can install cygwin, just remember to install bash terminal when cygwin setup is running.
Sent from my GT-P1000 using Tapatalk

Code:
mount -o rw,remount -t yaffs2 /dev/block/mtdblock3 /system
Click to expand...
Click to collapse
Galaxy S is running on yaffs2? Interesting
Code:
mount -o rw,remount /system
That should work too...

Is this the same as this?
http://forum.xda-developers.com/showthread.php?t=943588

Mackzen said:
Is this the same as this?
http://forum.xda-developers.com/showthread.php?t=943588
Click to expand...
Click to collapse
No:
The instructions from drakyy create a flashable ROM from the phone.
The Application from bohdans creates a flashable ROM from files on your computer

scheichuwe said:
Galaxy S is running on yaffs2? Interesting
Code:
mount -o rw,remount /system
That should work too...
Click to expand...
Click to collapse
Thanks - gonna change it in the first post

Verified?
Cool stuff Darkyy,
is this working without any issues, any testers?

mr_at_sgs said:
Cool stuff Darkyy,
is this working without any issues, any testers?
Click to expand...
Click to collapse
It's what we used for the Darky's Resurrection Edition

Damn. Left my laptop charger at work. Just when I need battery also.
Great thread. Thank you.
Tricky103 UltraSlim Essential Rom on DamianGTO Ultimate kernel

I have a problem. When tryign to create the tar-file i get:
cannot create jesper.tar: read-only file system.
What to do?

Does this also work when the partitions are NOT RFS.
Like all in ext4?
Will Odin be able to flash that image?
I somehow doubt it...

zurchpet said:
Does this also work when the partitions are NOT RFS.
Like all in ext4?
Will Odin be able to flash that image?
I somehow doubt it...
Click to expand...
Click to collapse
Good question..... I'd like to know this too..
Although even if having to disable lag fix to create it the apply again after flashing is still a quicker way to toggle between your current rom and cm7..

Neat Darky
but can i do these dumps on the phone without a pc or adb
Sent from my GT-I9000 using XDA App

Perhaps some could write a script to do this at the phone
Sent from my GT-I9000 using XDA App

[HOW TO][Windows] Manually Deodex and Odex back

The purpose of this thread is to give basics to manually deodex and odexing back framework and apk files​
Credits and Thanks to :
jubeh
Decad3nce
software_samurai
JKay
LeoMar75
and many others I forgot
Click to expand...
Click to collapse
Theory :
WHAT IS AN ODEX FILE?
In Android file system, applications and framework files come in packages with the extension .apk or .jar. These APKs or JARs 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 or JARs in a certain way, such that the .odex files are reassembled into classes.dex files directly integrated inside the APKs or JARs. By doing that, all pieces of an application package are put together back in one place.
For now, we need Baksmali.jar and Smali.jar to deodex, it seems these tools are not perfect and it seems to be why deodexed stock browser is laging/freezing.
This is the reason why there is a return to odexed customROMs
Click to expand...
Click to collapse
Prerequisites :
You will need these files :
* backsmali.jar
* smali.jar
* custom java.awt.jar
* dexopt wrapper
* recent version of busybox
Click to expand...
Click to collapse
all included in the attached .zip (end of post)
You will also need :
* your GS2
* with the official odexed firmware you want to mod
* rooted and with root explorer (pay app but really usefull) and with CWM recovery (better )
* ADB installed and working in su (#)
* copy dexopt-wrapper in /system/bin/ and giving it 755 permissions (using root explorer or command: chmod 755 /system/bin/dexopt-wrapper
* optional (if errors during odexing back) overwrite installed busybox with the one included here in /system/xbin/
Click to expand...
Click to collapse
You have to know :
* even on stock firmware (odexed) there are some deodexed .apk (like framework-res.apk in /system/framework/ and like some .apk in system/app/)
Tip on Windows "Vista / 7" : open a CMD prompt in a specified folder
1. Select the folder you want to open in the command prompt
2. Right-click on it while holding the Shift key
3. Select Open command window here
Click to expand...
Click to collapse
Manually Deodexing :
theory :
to decompil an odex file you need Baksmali.jar and you needs the BOOTCLASSPATH
BOOTCLASSPATH is a list in specific order of some framework .jar files
** To decompil and re-odex back .odex from JAR file you need to use the BOOTCLASSPATH specified in the init.rc file located in the root folder of your GS2 : (open init.rc with notepad ++)
Extract of I9100 init.rc :
export BOOTCLASSPATH /system/framework/core.jar:/system/framework/bouncycastle.jar:/system/framework/ext.jar:/system/framework/framework.jar:/system/framework/android.policy.jar:/system/framework/services.jar:/system/framework/core-junit.jar
** To decompil an .odex from APK file, BOOTCLASSPATH is different in fonction of the APKs, so the lazy way is to include all the .JAR files of the framework folder
2 applications : Emails.apk and MobilePrint.apk needs one more custom java.awt.jar
Click to expand...
Click to collapse
1/ put in the same folder :
* apk to deodex
* all system/framework files
add :
* custom java.awt.jar
* baksami.jar
* smali.jar
* zipalign.exe
Click to expand...
Click to collapse
2/ open CMD prompt in this folder (see above for how to)
3/ Deodexing Framework file (I will take android.policy.jar for example) :
* BAKSMALI of the android.policy.odex :
Code:
java -Xmx1024m -jar baksmali.jar -c :core.jar:bouncycastle.jar:ext.jar:framework.jar:android.policy.jar:services.jar:core-junit.jar -x [B]android.policy.odex[/B]
* This create an out folder. You can now modify some files (like adding Advanced power menu)
* SMALI the /out folder in a classes.dex file :
Code:
java -Xmx1024m -jar smali.jar [B]out[/B] -o classes.dex
* finally deodex your android.policy.jar :
open android.policy.jar with 7zip without extracting
push the classes.dex created in the 7zip window in the root folder
close the 7zip windows and here is your deodexed android.policy.jar
Click to expand...
Click to collapse
4/ Deodexing APK in system/app (I will take SystemUI.apk for exemple) :
* BAKSMALI of the SystemUI.odex :
Code:
java -Xmx1024m -jar baksmali.jar -c :am.jar:android.policy.jar:android.test.runner.jar:bmgr.jar:bouncycastle.jar:com.android.location.provider.jar:com.google.android.maps.jar:com.samsung.device.jar:com.yamaha.android.media.jar:core.jar:core-junit.jar:ext.jar:framework.jar:ime.jar:input.jar:[B]java.awt.jar[/B]:javax.obex.jar:libvtmanagerjar.jar:monkey.jar:pm.jar:sec_feature.jar:seccamera.jar:sechardware.jar:secmediarecorder.jar:services.jar:sqlite-jdbc.jar:svc.jar:twframework.jar -x [B]SystemUI.odex[/B]
* an out folder is created. You can modify the files inside if you want.
* SMALI the /out folder in a classes.dex file :
Code:
java -Xmx1024m -jar smali.jar [B]out[/B] -o classes.dex
* finally deodex your SystemUI.apk :
open SystemUI.apk with 7zip without extracting
push the classes.dex created in the 7zip window in the root folder
close the 7zip windows and here is your deodexed SystemUI.apk
Click to expand...
Click to collapse
* extra step for APKs : zipaplign of your new deodexed SystemUI.apk
--> In the same CMD prompt windows, type :
Code:
zipalign -v 4 SystemUI.apk zip_SystemUI.apk
A zip_SystemUI.apk file is created. Delete your deodexed SystemUI.apk and rename zip_SystemUI.apk in SystemUI.apk
ODEXING BACK :
the theory :
*You will need to copy the (custom) deodexed file (.jar or .apk) in the system/framework/ folder of your phone.
*You will use dexopt wrapper (already copied in your phone) to obtain a new .odex file (patched_android.policy.odex for example)
* You will copy the signature of original .odex file to patched.odex file - if not, the phone won't boot ...
Click to expand...
Click to collapse
How To :
1/ backup your original files (apk jar and odex) to /sdcard/Mod/
2/ copy modified deodexed files (.apk and .jar) in /system/framework/ of your GS2
Now we are going to odex back
3/ open a CMD prompt in the folder of adb.exe (usualy /android-sdk-windows/platform-tools/)
4/ type command :
Code:
adb shell
su
## for .JAR file :
dexopt-wrapper /system/framework/XXX.jar /system/framework/patched_XXX.odex /system/framework/core.jar:/system/framework/bouncycastle.jar:/system/framework/ext.jar:/system/framework/framework.jar:/system/framework/android.policy.jar:/system/framework/services.jar:/system/framework/core-junit.jar
response must be :
--- BEGIN '/system/framework/android.policy.jar' (bootstrap=0) ---
--- waiting for verify+opt, pid=7194
--- would reduce privs here
--- END '/system/framework/android.policy.jar' (success) ---
## for .APK file :
dexopt-wrapper /system/framework/XXX.apk /system/framework/patched_XXX.odex /system/framework/core.jar:/system/framework/bouncycastle.jar:/system/framework/ext.jar:/system/framework/framework.jar:/system/framework/android.policy.jar:/system/framework/services.jar:/system/framework/core-junit.jar
--> This will create the patched_XXX.odex file
Now we need to copy signature from original .odex file to patched .odex file cause Dalvik need files signature integrity in order to boot.
5/ always in the same CMD prompt windows :
Code:
# if not already done ...
adb shell
su
# copy the original .odex and .jar in system/framework (not .apk) :
cp /sdcard/MOD/original.XXX.odex /system/framework
cp -f /sdcard/MOD/XXX.jar /system/framework # where XXX.jar is the original odexed .jar
# give all permissions to XXX.odex files :
chmod 777 /system/framework/original.XXX.odex
chmod 777 /system/framework/patched_XXX.odex
# copy signature :
busybox dd if=/system/framework/original.XXX.odex of=/system/framework/patched_XXX.odex bs=1 count=20 skip=52 seek=52 conv=notrunc
response must be :
busybox dd if=/system/framework/original.XXX.odex of=/system/framewor
k/patched_XXX.odex bs=1 count=20 skip=52 seek=52 conv=notrunc
20+0 records in
20+0 records out
20 bytes (20B) copied, 0.002042 seconds, 9.6KB/s
Now the signature is copied over the patched_XXX.odex
Notice :
a - if you don't have response after busybox dd command : busybox is not installed or you have a to old version, use the busybox included in the attached .zip
b - if you don't have the last response line : 20 byt

Awesome! Thank you for your time sir!
Best regards,
aDEO

awesome man!'help me out of questions!

Thanks for the guide, just a quick question.
Can I odex a custom deodexed ROM? Just that will save me time.
If not, I'll unpack an official ROM and made my mods. You've posted some other great guides which has really helped me tonight! Thanks again.

nice tutorial
I've successfully deodex them.
lets try odex them back .

Mekrel said:
Thanks for the guide, just a quick question.
Can I odex a custom deodexed ROM? Just that will save me time.
If not, I'll unpack an official ROM and made my mods. You've posted some other great guides which has really helped me tonight! Thanks again.
Click to expand...
Click to collapse
Yes you can odex back a customROM (in theory) I never try to, but you will need to odex back all the .jar of the framework folder. And you will need the original firmware to copy signature of original .odex files to re-odexed .odex files
Sent from my GT-I9100 using XDA Premium App

abu2x said:
nice tutorial
I've successfully deodex them.
lets try odex them back .
Click to expand...
Click to collapse
Sometimes it will work the first time.
Sometimes it won't cause you forgot to give good permissions to dexopt-wrapper in system/bin
Or to the pached_XXX.odex files (need write permissions for all)
Or Busybox not installed or to old... Then the copy signature step won't work
Sent from my GT-I9100 using XDA Premium App

brilliant! thx a ton!

Great ! I was looking for this, thank you.
One thing was still giving me a hard time and i got that one solved also.
When doing a odex back from a custom theme, the method is different.
Because you need to use the modified framework file in the dependencylist.
So for me it was:
(I put a modified framework.jar in /sdcard)
dexopt-wrapper /sdcard/framework.jar /sdcard/framework.odex /system/framework/core.jar:/system/framework/bouncycastle.jar:/system/framework/ext.jar:/sdcard/framework.jar:/system/framework/android.policy.jar:/system/framework/services.jar:/system/framework/core-junit.jar
Otherwise it does NOT work. Now i have succusfully added overglow to a odex ROM.

Ok a new problem with the framework.jar
In the method to odex on the FP there was mentioned to use the dependency framework stuff.
When doing that trying to odex framework.jar i only get bootloops. aka the created odex file is wrong. The weird part is that the odex file created is 6,8 mb
When using the method i proposed in including the modified framework.jar in the dependencylist a bigger framework.odex is created. This one is about 7,14 mb
And it boots !
But it seems to be messed up because when trying to do some settings i get fc or it just exits. It appears to focus on phone settings. (try adding a apn and it closes)
Does anyone know of a solution for this ?
I did try to add the java.awt.jat in the dependencylist, but it does not seem to matter at all.

Yes you need to use your modded framework.jar in bootclasspath dependencies of dexopt wrapper.
If force close, perhaps you did not erase dalvik cache or made a mistake when modding framework.jar
Did you use the last Smali version out today x.7 to make your mod ? cause smali.jar was buggy with framwork.jar deodexing.
If you just want to odex a theme with more than 1 framework file, you should need to do by step : first you copy 1 file and odex it back then you do the same for second file ... You should only use 1 deodexed jar in your bootclasspath corresponding to the file you try to odex back.
Hope this will help, i cannot help much cause my GS2 doesn't really love the beautifull sand of the mediteraneen sea I am on vacation ...
Sent from my GT-I9100 using XDA Premium App

Thanx for the reply, i did just that.
The framework.jar file works flawlessly on a deodexed system, so i guess this file is ok.
But it does not work correctly when trying to odex back. I keep getting (thesame ) errors. Even doing a binary compare of the odex files when trying different methods to odex back is identical.
But the endresult is always thesame. The phone does boot but there are issues inside the jarfile.

Brotuck said:
Thanx for the reply, i did just that.
The framework.jar file works flawlessly on a deodexed system, so i guess this file is ok.
But it does not work correctly when trying to odex back. I keep getting (thesame ) errors. Even doing a binary compare of the odex files when trying different methods to odex back is identical.
But the endresult is always thesame. The phone does boot but there are issues inside the jarfile.
Click to expand...
Click to collapse
I just remember that original developper of overscroll glow for Galaxy S has stopped to dev odexed owerscroll glow cause of same errors (MMS)
I believe this due to a dexopt wrapper bug on odexing back framework.odex ??

smali / baksmali v1.2.8 is available

Hi Sicopat,
I'm having issues with this.
I'm currently running XXKG6 ROM that I've successfully deodexed and after reading your thread, I've wrote the below shell script that successfully runs.
Code:
#!/system/bin/sh
chmod 755 /system/bin/dexopt-wrapper
chmod 755 /system/bin/zip
coreframework="/system/framework/core.jar /system/framework/bouncycastle.jar /system/framework/ext.jar /system/framework/framework.jar /system/framework/android.policy.jar /system/framework/services.jar /system/framework/core-junit.jar"
echo "Odexing /system/framework/*jar files"
for i in $coreframework
do
filename=$(basename $i .jar)
dexopt-wrapper $i /system/framework/$filename.odex /system/framework/core.jar:/system/framework/bouncycastle.jar:/system/framework/ext.jar:/system/framework/framework.jar:/system/framework/android.policy.jar:/system/framework/services.jar:/system/framework/core-junit.jar
zip -d $i classes.dex
done
for i in /system/framework/*.jar
do
if [ $i == "/system/framework/core.jar" -o $i == "/system/framework/bouncycastle.jar" -o $i == "/system/framework/ext.jar" -o $i == "/system/framework/framework.jar" -o $i == "/system/framework/android.policy.jar" -o $i == "/system/framework/services.jar" -o $i == "/system/framework/core-junit.jar" ]
then
echo "Already odexed in sequence"
else
filename=$(basename $i .jar)
dexopt-wrapper $i /system/framework/$filename.odex /system/framework/core.jar:/system/framework/bouncycastle.jar:/system/framework/ext.jar:/system/framework/framework.jar:/system/framework/android.policy.jar:/system/framework/services.jar:/system/framework/core-junit.jar
zip -d $i classes.dex
fi
done
echo "Giving permissions to all *odex files"
chmod -R 777 /sdcard/original-framework/*.odex
chmod -R 777 /system/framework/*.odex
echo "Copying signatures from original odex files"
for i in /sdcard/original-framework/*.odex
do
filename=$(basename $i .odex)
busybox dd if=$i of=/system/framework/$filename.odex bs=1 count=20 skip=52 seek=52 conv=notrunc
done
rm -r /data/dalvik-cache/*
The script does the following process:
Sets permisions for the dexopt-wrapper and zip binaries.
Odexes the core framework in the same order they're listed in BOOTCLASSPATH in init.rc.
Odexes the other framework files that were not previously odexed
Copies the signatures from the original XXKG6 .odex files, to the ones that have just been created (the origials are stored on the sdcard)
The only difference in the script I wrote is the classes.dex are removed from the .jar files using the zip binary.
I can see the .odex files created when running a ls /system/framework command and pulling the .jar files reveals that the dex file from inside has been removed.
I've also tried copying the original .jar files over, rather than removing the .dex files on the fly.
However, the phone doesn't even boot, i.e. it doesn't even get past the splash image.
Can you see anything wrong with my logic/shell script?
Many thanks
Mark

Mekrel said:
Hi Sicopat,
I'm having issues with this.
I'm currently running XXKG6 ROM that I've successfully deodexed and after reading your thread, I've wrote the below shell script that successfully runs.
Code:
#!/system/bin/sh
chmod 755 /system/bin/dexopt-wrapper
chmod 755 /system/bin/zip
coreframework="/system/framework/core.jar /system/framework/bouncycastle.jar /system/framework/ext.jar /system/framework/framework.jar /system/framework/android.policy.jar /system/framework/services.jar /system/framework/core-junit.jar"
echo "Odexing /system/framework/*jar files"
for i in $coreframework
do
filename=$(basename $i .jar)
dexopt-wrapper $i /system/framework/$filename.odex /system/framework/core.jar:/system/framework/bouncycastle.jar:/system/framework/ext.jar:/system/framework/framework.jar:/system/framework/android.policy.jar:/system/framework/services.jar:/system/framework/core-junit.jar
zip -d $i classes.dex
done
for i in /system/framework/*.jar
do
if [ $i == "/system/framework/core.jar" -o $i == "/system/framework/bouncycastle.jar" -o $i == "/system/framework/ext.jar" -o $i == "/system/framework/framework.jar" -o $i == "/system/framework/android.policy.jar" -o $i == "/system/framework/services.jar" -o $i == "/system/framework/core-junit.jar" ]
then
echo "Already odexed in sequence"
else
filename=$(basename $i .jar)
dexopt-wrapper $i /system/framework/$filename.odex /system/framework/core.jar:/system/framework/bouncycastle.jar:/system/framework/ext.jar:/system/framework/framework.jar:/system/framework/android.policy.jar:/system/framework/services.jar:/system/framework/core-junit.jar
zip -d $i classes.dex
fi
done
echo "Giving permissions to all *odex files"
chmod -R 777 /sdcard/original-framework/*.odex
chmod -R 777 /system/framework/*.odex
echo "Copying signatures from original odex files"
for i in /sdcard/original-framework/*.odex
do
filename=$(basename $i .odex)
busybox dd if=$i of=/system/framework/$filename.odex bs=1 count=20 skip=52 seek=52 conv=notrunc
done
rm -r /data/dalvik-cache/*
The script does the following process:
Sets permisions for the dexopt-wrapper and zip binaries.
Odexes the core framework in the same order they're listed in BOOTCLASSPATH in init.rc.
Odexes the other framework files that were not previously odexed
Copies the signatures from the original XXKG6 .odex files, to the ones that have just been created (the origials are stored on the sdcard)
The only difference in the script I wrote is the classes.dex are removed from the .jar files using the zip binary.
I can see the .odex files created when running a ls /system/framework command and pulling the .jar files reveals that the dex file from inside has been removed.
I've also tried copying the original .jar files over, rather than removing the .dex files on the fly.
However, the phone doesn't even boot, i.e. it doesn't even get past the splash image.
Can you see anything wrong with my logic/shell script?
Many thanks
Mark
Click to expand...
Click to collapse
Okay, I actually got this to work by removing the copying of signatures from the stock .odex files to the new ones.
I find that a little weird seeing as that step is specifically mentioned in your guide and that the phone is supposedly unable to boot without copying the signature.

After deodexing (and not odexing back) my framework and app folder of my custom ROM in my kitchen (before flashing),
is it necessary to sign/resign apks?

ok i have a few questions if you wouldnt mind helping.
i've been using androids since July of this year, only 2 months now, so i'm really new to modding...
i'm trying very hard to catch on and to learn...
unfortunately, i purchased a device with absolutely no development
anyway, assuming that you'll help, i'll proceed...
i'm not on a galaxy s II - i'm doing this on a gravity smart.
our bootclass path is different:
system/framework/core.jar:/system/framework/ext.jar:/system/framework/framework.jar:/system/framework/android.policy.jar:/system/framework/services.jar
your bootclass path:
/system/framework/core.jar:/system/framework/bouncycastle.jar:/system/framework/ext.jar:/system/framework/framework.jar:/system/framework/android.policy.jar:/system/framework/services.jar:/system/framework/core-junit.jar
so i removed the difference in your command example to this:
java -Xmx1024m -jar baksmali.jar -c :core.jar:framework.jar:android.policy.jar:services.jar -x android.policy.odex
all is fine, i get an "out" folder created with files in it
i then use your command example:
java -Xmx1024m -jar smali.jar out -o classes.dex
and a classes.dex is created
i then opened the android.policy.jar with 7zip and dropped the classes.dex file in its root
i'm assuming the process is going as its supposed to at this point.
question 1: am i doing this right?
question 2: do i do this to all the .jars in the /system/framework/ directory to have a completely deodexed system (and of course all the /system/app/files)?
question 3: do i also use these methods or the apk methods listed on your 2nd post to do the twframework-res.apk file?
question 4: do i create a new "out" folder for each .jar (run the command line for each .jar) or do i use the first created classes.dex for all the .jar files in /system/framework/ directory?
question 5: after i create the deodexed files i can safely delete the .odex companion files correct? (this may be a dumb question with an obvious answer, but i don't want to screw up)
question 6: can i place the deodexed files on the sdcard and move them with root explorer or do i need to push them thru using ADB?
any help or suggestions would be greatly appreciated!

NitroOnTheRocks said:
After deodexing (and not odexing back) my framework and app folder of my custom ROM in my kitchen (before flashing),
is it necessary to sign/resign apks?
Click to expand...
Click to collapse
Nope
Sent from my GT-I9100 using xda premium

Arhtard said:
ok i have a few questions if you wouldnt mind helping.
i've been using androids since July of this year, only 2 months now, so i'm really new to modding...
i'm trying very hard to catch on and to learn...
unfortunately, i purchased a device with absolutely no development
anyway, assuming that you'll help, i'll proceed...
i'm not on a galaxy s II - i'm doing this on a gravity smart.
our bootclass path is different:
system/framework/core.jar:/system/framework/ext.jar:/system/framework/framework.jar:/system/framework/android.policy.jar:/system/framework/services.jar
your bootclass path:
/system/framework/core.jar:/system/framework/bouncycastle.jar:/system/framework/ext.jar:/system/framework/framework.jar:/system/framework/android.policy.jar:/system/framework/services.jar:/system/framework/core-junit.jar
so i removed the difference in your command example to this:
java -Xmx1024m -jar baksmali.jar -c :core.jar:framework.jar:android.policy.jar:services.jar -x android.policy.odex
all is fine, i get an "out" folder created with files in it
i then use your command example:
java -Xmx1024m -jar smali.jar out -o classes.dex
and a classes.dex is created
i then opened the android.policy.jar with 7zip and dropped the classes.dex file in its root
i'm assuming the process is going as its supposed to at this point.
question 1: am i doing this right?
question 2: do i do this to all the .jars in the /system/framework/ directory to have a completely deodexed system (and of course all the /system/app/files)?
question 3: do i also use these methods or the apk methods listed on your 2nd post to do the twframework-res.apk file?
question 4: do i create a new "out" folder for each .jar (run the command line for each .jar) or do i use the first created classes.dex for all the .jar files in /system/framework/ directory?
question 5: after i create the deodexed files i can safely delete the .odex companion files correct? (this may be a dumb question with an obvious answer, but i don't want to screw up)
question 6: can i place the deodexed files on the sdcard and move them with root explorer or do i need to push them thru using ADB?
any help or suggestions would be greatly appreciated!
Click to expand...
Click to collapse
Q1/ yes
Q2/ yes if you want a deodexed Rom
Q3/you don't need to deodex twframework and framework-res ...
Q4/ you need to backsmali every files. You can rename out folders to core, android.policy, ... And replace out with the "name of folder" in smali command. Classes.dex is specific of 1 file
Q5Yes, you can delete odex files. This is the point of deodexing
Q6/ you can do the 2 ways, to try if deodexed files are correct, then correct the permissions and then backup and delete odex file. But for entire rom, the better is to use a non wipe script and to flash the entire deodexed Rom.
Finaly, there are many deodexing auto kit. I made an How to deodex resign and zipalign a customRom, try the kit-Deodexage included.
Or look for more used deodex script cause there are many apks to deodex, doing this manually will be very long ...
Sent from my GT-I9100 using xda premium

[TUTORIAL] Making Flashable ZIPs, EDIFY Script, ZIP Signing & Key Creation [19.01.13]

[TUTORIAL] Making Flashable ZIPs, EDIFY Script, ZIP Signing & Key Creation [19.01.13]
Recent Updates: Command Line Edify Script Tester, Further 'update-binary' info clarification, helpful links, additional credits. post#1
Hi all,
In the process of creating my [BOOTANIMATIONS - LINKS & INFO] thread I realised I needed to know more about how boot animations worked, as by default people tend to ask questions in that type of thread, so I wanted to be able to help.
This meant I came across the problem of creating flash-able ZIP files and Edify scripting and in the interests of sharing and helping this great community I would like to share what I have found and hopefully learn more through discussion, I certainly am no expert and am always willing to learn.
I have checked xda and various other websites whilst reseraching for this post and there is nothing that really explains all the basic concepts to just get up and running, also a lot of threads are quite old and focus on the old Amend scripting syntax or are a confusing mixture of the two.
I hope this helps people get started and that we can all collaborate to make this a thread a source of valuable information.
Contents:
Post #1: Tutorials
Post #2: Edify Commands
***Please, if there are any mistakes on this thread then let me know what I have done incorrectly in reply to this post and I will update the thread to correct it***
***As always, I accept no responsibiltiy for your handset, you modify it at your own risk, nobody is forcing you...be aware you can seriously bork your phone by flashing its internal partitions! Always make a nandroid back-up and think before you flash!***
***Have you made a nandroid back-up...no? Then make one!!***
You will need the following:
Android SDK, ADB & Fastboot set up for your handset.
Notepad++ [LINK]
7zip [LINK]
Setting up your zip directories:
you will need to create the following folder structure (these are case sensitive):
Code:
/META-INF/com/google/android
All flash-able zips include this file structure, the final folder 'android' will contain two files:
Code:
update-binary
updater-script
update-binary: I have been unable to find much information on the update-binary file other than they seem to be chip set specific (if anyone can shed further light on these I will include it here). For the sake of compatibility I have attached the update binary from the latest CyanogenMod Nightlies for the maguro at the bottom of this thread - You can of course download the latest nightly and extract the update-binary file yourself as the attached one will obviously begin to date (all credit to the great devs at CyanogenMod for this, many thanks).
Update: For more detailed info on the update binary you can find the sources in the bootable/recovery/updater directory at AndroidXRef here: [ xref: /bootable/recovery/updater/ ]. There is also an edify directory which looks like it handles the parsing of the script. Obviously with the sources there's nothing to stop you extending syntax/functionality should you wish given the fact the each zip comes with its own version. It will also help you understand how signature checking is handled.
Update II: For anybody having problems flashing it is worth ensuring you have an up to date version of the update-binary (obviously the one attached to this thread will gradually become out of date).
It is advisable to use the update-binary from the latest OTA image for your device, these images can be found in the following link:
Official Google OTA update URLs - efrant
updater-script: This we can create ourselves, to ensure it works properly we will use Notepad++.
Open Notepad++ and start a new file, with the following settings:
Format: Unix
Encoding: ANSI
Default Language: Normal Text
Save this file as:
File name: updater-script
File type: All types (*.*)
You can now edit this file, add the following text:
Code:
[COLOR="Red"]assert(getprop("ro.product.device") == "maguro" || getprop("ro.build.product") == "maguro");[/COLOR]
[COLOR="Green"]ui_print(" ");[/COLOR]
[COLOR="green"]ui_print("confirming device maguro");[/COLOR]
[COLOR="green"]ui_print(" ");[/COLOR]
[COLOR="green"]ui_print("success");[/COLOR]
[COLOR="green"]ui_print(" ");[/COLOR]
[COLOR="DarkOrange"]show_progress(0.200000, 5);[/COLOR]
[COLOR="green"]ui_print("mounting system");[/COLOR]
[COLOR="red"]mount("ext4", "EMMC", "/dev/block/platform/omap/omap_hsmmc.0/by-name/system", "/system");[/COLOR]
[COLOR="green"]ui_print(" ");[/COLOR]
[COLOR="DarkOrange"]show_progress(0.200000, 5);[/COLOR]
[COLOR="green"]ui_print("updating system files");[/COLOR]
[COLOR="red"]package_extract_dir("system", "/system");[/COLOR]
[COLOR="green"]ui_print(" ");[/COLOR]
[COLOR="DarkOrange"]show_progress(0.200000, 5);[/COLOR]
[COLOR="green"]ui_print("unmounting system");[/COLOR]
[COLOR="red"]unmount("/system");[/COLOR]
[COLOR="green"]ui_print(" ");[/COLOR]
[COLOR="DarkOrange"]show_progress(0.200000, 5);[/COLOR]
[COLOR="green"]ui_print("by yourusername");[/COLOR]
[COLOR="DarkOrange"]show_progress(0.200000, 5);[/COLOR]
[COLOR="green"]ui_print(" ");[/COLOR]
***EMPTY LINE***
Ok, I've colour coded this so we can break it down, the lines of code in RED are the actual commands, everything else is cosmetic.
assert(getprop("ro.product.device") == "maguro" || getprop("ro.build.product") == "maguro"); This is checking you are flashing the correct handset, this is not a requirement, but is best practice. Just insert another device name in the place of "maguro" if you so wish, or remove the command all together.
mount("ext4", "EMMC", "/dev/block/platform/omap/omap_hsmmc.0/by-name/system", "/system"); This is the specific mount point for the maguro system partition, if you wish to flash a different partition, data for instance you can get the mount points for your device by entering the following code over ADB:
Code:
adb shell "mount > /sdcard/PHONENAME_mountinfo.txt"
This will place a text file on your sdcard with the mount points for your specific device (remember to swap 'PHONENAME' with your device name e.g. 'maguro')
package_extract_dir("system", "/system"); This command extracts the files you wish to flash from the zip and flashes them to the phone, it is formatted as follows ("package-path", "/destination-path"). So for this example you are telling it to flash everything from the 'system' folder in your zip to the /system partition of your handset. You can obviously change these values for different partitions.
unmount("/system"); This simply unmounts whatever partition you previously mounted.
ui_print(" "); Shows text in the recovery whilst the flash is ongoing, you can put whatever you please between the speech marks, you must leave a space if you wish to have a blank line.
show_progress(0.200000, 5); Controls what the progress bar in the background is displaying, it is formatted as follows (fragment, seconds).
***EMPTY LINE*** This is not actually text, you simply need to leave a blank line at the end of your script before you save it for it to work.
FYI, this means in fact your script could look like this and still work:
Code:
[COLOR="Green"]ui_print(" ");[/COLOR]
[COLOR="DarkOrange"]show_progress(1.000000, 30);[/COLOR]
[COLOR="red"]mount("ext4", "EMMC", "/dev/block/platform/omap/omap_hsmmc.0/by-name/system", "/system");[/COLOR]
[COLOR="red"]package_extract_dir("system", "/system");[/COLOR]
[COLOR="red"]unmount("/system");[/COLOR]
[COLOR="Green"]ui_print(" ");[/COLOR]
***EMPTY LINE***
But that just isn't that pretty, or as deceptively complicated lol!
Make sure you save your edify script.
Files to flash:
You now need to create a further folder, this needs to be named based on where within the system you are flashing, for the sake of this example we are flashing to the system partition, so:
Code:
/META-INF/com/google/android
/system/app
Place whatever files you wish to flash within this file e.g:
Code:
/META-INF/com/google/android
/system/app/nameofapp.apk
Creating your .zip file:
Select both of your top directories and their contents 'META-INF' and 'system' and package them into a .zip file with 7zip using the following settings:
Archive: name_of_your_file
Archive Format: zip
Compression level: Store
Update mode: Add and replace files
And there you have it, your very own flash-able .zip file.
I have attached an example flashable .zip file that includes this updater-script and the above mentioned CM update-binary.
How to sign your update.zip:
You don't actually need to sign your zip file for it to work as most custom recoveries now support unsigned zips, for aspiring developers and the more cautious among us though, here is how.
You will need to download the following files:
SignApk [LINK]
Java JDK (Java Development Kit) & JRE (Java Runtime Environment) [LINK]
Install Java JRE and JDK and restart your PC.
You then need to create a folder in the root of your c:\ drive named 'signapk' and extract the contents of the SignApk download (signapk.jar, key.pk8, certificate.pem) to this folder.
Place your .zip file into the same folder and then open cmd line. Input the following commands (remeber to change the name of 'myupdate.zip' to the name of your file and 'myupdate-signed.zip' to whatever you want your resulting .zip to be named):
Code:
cd\signapk\
java -jar signapk.jar certificate.pem key.pk8 c:\signapk\myupdate.zip myupdate-signed.zip
You should find that you now have the the following files in your 'META-INF' folder: CERT.RSA, CERT.SF, MANIFEST.MF
This can also to be used to sign .apk files using the below command (same stipulations for file name changing applies as above):
Code:
java -jar signapk.jar certificate.pem key.pk8 c:\signapk\myapplication.apk myapplication-signed.apk
How to create your own private signing key & certificate:
You will need the following download:
OpenSSL [LINK]
The above signapk file includes test keys, if you want to create your own private keys for signing, here's what you need to do.
As before extract the OpenSSL files to a folder in the root of your c:\ drive, preferably named 'openssl' for ease of cmd line navigation. Then input the following:
Code:
cd\openssl\
openssl genrsa -out key.pem 1024
openssl req -new -key key.pem -out request.pem
openssl x509 -req -days 9999 -in request.pem -signkey key.pem -out certificate.pem
openssl pkcs8 -topk8 -outform DER -in key.pem -inform PEM -out key.pk8 -nocrypt
You can then replace 'key.pk8' & 'certificate.pem' with your own files.
I really hope this has helped folks out, if so please consider hitting the 'Thanks' button!
Happy flashing!
Testing your script before you flash:
If you would like to test if your script commands are valid and will run properly on your PC first before you use them on your handset, therefore removing the fear of borking your current install/handset in the process then head to this post:
Command Line Edify Script Tester by: trevd
This great tool developed by trevd currently has the following features:
Validates function name.
Validates function parameter count.
It is available for Linux and Windows, so head over and check it out. Be sure to click trevd's thanks button if you find this useful.
Other helpful links & threads:
xda-developers: Edify script language wiki
Edify scripts in CWM recovery by: NFHimself
Phandroid - Edify Script Language Reference by: Koumajutsu
Introduction to edify updater script by: kurotsugi
Intelligent EDIFY updater-script - (Decides things during flash) by: lotherius
Credits:
CyanogenMod for (update-binary)
Lorenz's Blog for (SignAPK & Info)
JoeSyr for (Help with File Permissions)
efrant for (Help with various commands)
trevd for (further update-binary clarification and source links)
osm0sis for (Helpful info & forum links & help with update-binary info)

Edify Scripting Commands
I would like to try and put together a guide to Edify scripting commands and what their function is to compliment my above tutorial, I hope again we can all collaborate to make this a helpful source of information to all budding devs...we all have to start somewhere right!?
***Please, if there are any mistakes in this post or if you can help by adding further info please post below, thanks***
Ok...
Check you are flashing the correct device:
Code:
assert(getprop("ro.product.device") == "maguro" || getprop("ro.build.product") == "maguro" || getprop("ro.product.board") == "maguro");
This will check your device is showing the correct name in the build.prop, in this case "maguro", you can obviously replace this with your device name.
To explain this a little further, you have told the script to check certain properties within your 'build.prop' file located in your /system folder. The above command ensures the following categories have the correct definitions before proceeding with the flash:
Code:
ro.product.device=
ro.build.product=
ro.product.board=
Here are the main build properties within your build.prop:
Code:
ro.build.id=
ro.build.display.id=
ro.build.version.incremental=
ro.build.version.sdk=
ro.build.version.codename=
ro.build.version.release=
ro.build.date=
ro.build.date.utc=
ro.build.type=
ro.build.user=
ro.build.host=
ro.build.tags=
ro.product.model=
ro.product.brand=
ro.product.name=
ro.product.device=
ro.product.board=
ro.product.cpu.abi=
ro.product.cpu.abi2=
ro.product.manufacturer=
ro.product.locale.language=
ro.product.locale.region=
ro.wifi.channels=
ro.board.platform=
ro.build.description=
ro.build.fingerprint=
ro.build.characteristics=
ro.cm.device=
Print text in the recovery during flashing process:
Code:
ui_print("Your text here");
Code:
ui_print(" ");
This simply prints a line of text in the recovery, it has no actual effect on the flashing process, if you want a blank line just leave a blank space as the second example.
Controlling the progress bar:
I believe I understand this correctly, if not please do post below with further clarification.
Code:
show_progress(0.000000, 0);
or
Code:
set_progress(0.000000);
You have two choices when controlling the progress bar, the first example allows you to define fractions of the progress bar and how long they will take to fill. The second example just allows you to specify that the bar fills to a certain fraction at whatever point during the flashing process.
The command is defined as: (progress bar fraction, duration in seconds to fill defined fraction);
For example the following code lines interspersed with your other commands would fill a fifth of the progress bar every five seconds:
Code:
show_progress(0.200000, 5);
ui_print(" ");
show_progress(0.200000, 5);
ui_print(" ");
show_progress(0.200000, 5);
ui_print(" ");
show_progress(0.200000, 5);
ui_print(" ");
show_progress(0.200000, 5);
This process will only complete if the script takes long enough to flash, therefore you need to be aware of what you are actually flashing and how long it will take when defining these values.
If you wish to just define a fraction without fill without a time scale you can use the following command:
Code:
set_progress(0.000000);
It is also best practice to include this element in your scripts as it will reassure people that their handset hasn't frozen during a flash.
Mount/Unmount a partition:
To mount a partition you need to use the following syntax:
Code:
mount("filesystem-type", "partition-type", "device-specific-location", "mount-point");
filesystem-type: "ext4" or "yaffs2" (maguro is ext4)
partition-type: "EMMC" or "MTD" (maguro is EMMC)
location: Device specific address
mount-point: /system etc
So far I have managed to define the following Maguro specific mount points:
Code:
"/dev/block/platform/omap/omap_hsmmc.0/by-name/system", "/system"
"/dev/block/platform/omap/omap_hsmmc.0/by-name/userdata", "/data"
"/dev/block/platform/omap/omap_hsmmc.0/by-name/cache", "/cache"
"/dev/block/platform/omap/omap_hsmmc.0/by-name/efs" "/factory"
"/dev/block/platform/omap/omap_hsmmc.0/by-name/userdata", "/mnt/sdcard"
"/dev/block/platform/omap/omap_hsmmc.0/by-name/boot"
Example command would be:
Code:
mount("ext4", "EMMC", "/dev/block/platform/omap/omap_hsmmc.0/by-name/system", "/system");
I have taken these mount points from the file output by the maguro when you enter the following adb command:
Code:
adb shell "mount > /sdcard/maguro_mountinfo.txt"
I have to admit I am a little in the dark about the "/factory" partition, any info would be greatly appreciated!
To unmount a partition you need to input the following command:
Code:
unmount("/system");
Obviously replace the mount partition with whatever partition you are working in.
Format a partition:
To format a partition you need to use the following syntax:
Code:
format("filesystem-type", "partition-type", "device-specific-location", "0");
Example:
Code:
format("ext4", "EMMC", "/dev/block/platform/omap/omap_hsmmc.0/by-name/system", "0");
Some scripts include the "0" and some do not, not sure exactly on the function difference when included or not, again clarification would be great.
Flashing the contents of your ZIP file:
To flash an entire directory:
Code:
package_extract_dir("system", "/system");
To flash a single file:
Code:
package_extract_file("boot.img", "/dev/block/platform/omap/omap_hsmmc.0/by-name/boot");
These commands are structured as follows:
Entire directory: ("zipfileSource", "destination-partition");
Single File: ("file", "device-specific-mountpoint");
Deleting folders & files:
You can delete multiple folders or files using just one command, as follows:
To delete files:
Code:
delete("file-path-1", "file-path-2", "file-path-3);
To delete folders/directories:
Code:
delete_recursive("directory-path-1", "directory-path-2", "directory-path-3");
Setting Permissions
Here are the basics for setting permissions.
If you want to research the reasons behind this, there is some useful information on Linux permissions here: chmod wiki, linuxquestions.org linux wiki.
Thanks to JoeSyr for his input and help understanding this section of the tutorial.
Set permissions of a file or set of files:
Code:
set_perm(uid, gid, mode, "filepath1", "filepath2")
Example:
Code:
set_perm(0, 0, 06755, "/system/xbin/su");
uid - user id
gid - group id
mode - permission mode
filepath... - file to set permission on
Set permissions of a directory or set of directories and all files and folders within them:
Code:
set_perm_recursive(uid, gid, dirmode, filemode, "dirpath1", "dirpath2")
Example:
Code:
set_perm_recursive(0, 0, 0755, 0644, "/system");
uid - user id
gid - group id
dirmode - permission to set to directories contained within the specified directory
filemode - permission to set to files contained within the specified directory
dirpath... - directory to set permission on
Permissions syntax explained...so I can understand it lol (if I do then anyone can!):
The following are the pre-defined Android UID's & GID's. Taken from the following link: Android UIDs and GIDs
Code:
AID_ROOT 0 /* traditional unix root user */
AID_SYSTEM 1000 /* system server */
AID_RADIO 1001 /* telephony subsystem, RIL */
AID_BLUETOOTH 1002 /* bluetooth subsystem */
AID_GRAPHICS 1003 /* graphics devices */
AID_INPUT 1004 /* input devices */
AID_AUDIO 1005 /* audio devices */
AID_CAMERA 1006 /* camera devices */
AID_LOG 1007 /* log devices */
AID_COMPASS 1008 /* compass device */
AID_MOUNT 1009 /* mountd socket */
AID_WIFI 1010 /* wifi subsystem */
AID_ADB 1011 /* android debug bridge (adbd) */
AID_INSTALL 1012 /* group for installing packages */
AID_MEDIA 1013 /* mediaserver process */
AID_DHCP 1014 /* dhcp client */
AID_SHELL 2000 /* adb and debug shell user */
AID_CACHE 2001 /* cache access */
AID_DIAG 2002 /* access to diagnostic resources */
/* The 3000 series are intended for use as supplemental group id's only. */
/* They indicate special Android capabilities that the kernel is aware of. */
AID_NET_BT_ADMIN 3001 /* bluetooth: create any socket */
AID_NET_BT 3002 /* bluetooth: create sco, rfcomm or l2cap sockets */
AID_INET 3003 /* can create AF_INET and AF_INET6 sockets */
AID_NET_RAW 3004 /* can create raw INET sockets */
AID_MISC 9998 /* access to misc storage */
AID_NOBODY 9999
AID_APP 10000 /* first app user */
"root", AID_ROOT
"system", AID_SYSTEM
"radio", AID_RADIO
"bluetooth", AID_BLUETOOTH
"graphics", AID_GRAPHICS
"input", AID_INPUT
"audio", AID_AUDIO
"camera", AID_CAMERA
"log", AID_LOG
"compass", AID_COMPASS
"mount", AID_MOUNT
"wifi", AID_WIFI
"dhcp", AID_DHCP
"adb", AID_ADB
"install", AID_INSTALL
"media", AID_MEDIA
"shell", AID_SHELL
"cache", AID_CACHE
"diag", AID_DIAG
"net_bt_admin", AID_NET_BT_ADMIN
"net_bt", AID_NET_BT
"inet", AID_INET
"net_raw", AID_NET_RAW
"misc", AID_MISC
"nobody", AID_NOBODY
You will need to also understand the way file permissions are represented:
Example = drwxrwxrwx
-Use Root Explorer to find the UID, GID, and permissions for a file. Permissions are the string that looks like some variation on 'rwxr-xr--' next to each file. Long press and choose "change owner" to get the UID and GID. You just want the number next to "owner" and "group", respectively.
-If you're replacing a file, look up these settings for the existing copy and use them. If you're adding a file, just find a file that does the same functions and copy what it has (for example, installing an app to /system/app? Just look at these settings for any other app in that directory).
-MODE is technically a 4-bit string, but the first character can be omitted. There doesn't seem to be any android file permissions with the first character set. For good practice, I think it's safe to assume you can always use a leading 0 unless you know otherwise for something specific. Or, just use a 3-digit MODE, which says to leave those settings as they are (disabled by default). (I.e. 0644=644).
The next 9 characters define the file permissions. These permissions are
given in groups of 3 each.
The first 3 characters are the permissions for the owner of the file or directory.
Example = -rwx------
The next 3 are permissions for the group that the file is owned by.
Example = ----rwx---
The final 3 characters define the access permissions for everyone not part of the group.
Example = -------rwx
There are 3 possible attributes that make up file access permissions.
r - Read permission. Whether the file may be read. In the case of a
directory* this would mean the ability to list the contents of the
directory.
w - Write permission. Whether the file may be written to or modified. For
a directory* this defines whether you can make any changes to the contents
of the directory. If write permission is not set then you will not be able
to delete* rename or create a file.
x - Execute permission. Whether the file may be executed. In the case of a
directory* this attribute decides whether you have permission to enter*
run a search through that directory or execute some program from that
directory
You set these permissions using the following binary based numerical system:
Code:
0: --- No Permissions (the user(s) cannot do anything)
1: --x Execute Only (the user(s) can only execute the file)
2: -w- Write Only (the user(s) can only write to the file)
3: -wx Write and Execute Permissions
4: r-- Read Only
5: r-x Read and Execute Permissions
6: rw- Read and Write Permissions
7: rwx Read, Write and Execute Permissions
Default Linux permissions:
For Files:
"Read" means to be able to open and view the file
"Write" means to overwrite or modify the file
"eXecute" means to run the file as a binary
For Directories:
"Read" means to be able to view the contents of the directory
"Write" means to be able to create new files/directories within the directory
"eXecute" means to be able to "Change Directory" (cd) into the directory
Most of the time you set "Read" and "eXecute" together on directories (kind of useless when set by themselves)
Interestingly through further research it seems this system is based on the Octal Binary system...I may be wrong...
Code:
Octal
Binary is also easily converted to the octal numeral system, since octal uses a radix of 8, which is a power of two (namely, 23, so it takes exactly three binary digits to represent an octal digit).
The correspondence between octal and binary numerals is the same as for the first eight digits of hexadecimal in the table above.
Binary 000 is equivalent to the octal digit 0, binary 111 is equivalent to octal 7, and so forth.
Octal Binary
0 000
1 001
2 010
3 011
4 100
5 101
6 110
7 111
Converting from octal to binary proceeds in the same fashion as it does for hexadecimal:
658 = 110 1012
178 = 001 1112
And from binary to octal:
1011002 = 101 1002 grouped = 548
100112 = 010 0112 grouped with padding = 238
And from octal to decimal:
658 = (6 × 81) + (5 × 80) = (6 × 8) + (5 × 1) = 5310
1278 = (1 × 82) + (2 × 81) + (7 × 80) = (1 × 64) + (2 × 8) + (7 × 1) = 8710
Flash boot partition
This uses the following command but with some caveats:
Code:
write_raw_image("path to boot.img", "boot");
An example of this commands use would be to flash a custom kernel, as far as I can tell though you need to place the boot.img in a temp file before the actual flash (clarification on this would be helpful). You would therefore use the following commands as part of your edify script:
Code:
package_extract_file("boot.img","/tmp/boot.img");
write_raw_image("/tmp/boot.img", "device-specific-boot-partition-mount-point");
delete("/tmp/boot.img");
It seems this may only be for specific handsets though e.g HTC, having looked through quite a few updater-script files from maguro zips it seems this can just be flashed directly with the following command:
Code:
package_extract_file("boot.img", "/dev/block/platform/omap/omap_hsmmc.0/by-name/boot");
Many thanks for further clarification on this particular command from efrant below:
I feel more comfortable using something like this:
Code:
package_extract_file("boot.img", "/tmp/boot.img");
run_program("/sbin/busybox", "dd", "if=/tmp/radio.img", "of=/dev/block/platform/omap/omap_hsmmc.0/by-name/boot");
delete("/tmp/boot.img")
The second line is using the "dd" command to flash the image.
The dd command (included in busybox) is:
Code:
dd if=xxx of=yyy
where xxx is the source image/partition and yyy is the target image/partition. So, for example, to flash a radio image stored in /sdcard called xxlf1.img to a GNex, it would be:
Code:
busybox dd if=/sdcard/xxlf1.img of=/dev/block/platform/omap/omap_hsmmc.0/by-name/radio (I've added "busybox" the the beginning, just to be explicit.)
So, to put it in edify format, it becomes:
Code:
run_program("/sbin/busybox", "dd", "if=/sdcard/xxlf1.img", "of=/dev/block/platform/omap/omap_hsmmc.0/by-name/radio");
However, as I said, I believe your one line:
Code:
package_extract_file("boot.img", "/dev/block/platform/omap/omap_hsmmc.0/by-name/boot");
would work.
Further Commands:
In progress...
So, this is by no means an exhaustive list and I would appreciate it that if I have made any mistakes people make me aware in this thread and I can update this tutorial.
I would also like to add further commands and their uses, if people can provide more I will add them too.
I hope this helps people out! Many thanks!

Thx for your work. Will try it when I back @ home.
Mfg Daniel
Gesendet von meinem Galaxy Nexus mit Tapatalk 2

very interesting 3ad.i'm learning right now how to make these,yours guide resolve me a lot of questions!thanks mate!+1

Awesome. Thank you!

Thanks for the feedback folks!
Top post updated with guides for:
Signing ZIP files
Creating private ZIP signing keys

I have updated the second post with edify commands:
Contents:
Post #1: Tutorials
Post #2: Edify Commands
I would like to expand and update this information to help both others and myself learn, if people can help with more commands or any corrections this would be much appreciated!

Thanx a lot . Ive been looking into editing apks and themeing and this answers a lot of my questions. Exactly what I've been looking for.
Sent from my Galaxy Nexus using XDA

graffitiwriter said:
Thanx a lot . Ive been looking into editing apks and themeing and this answers a lot of my questions. Exactly what I've been looking for.
Click to expand...
Click to collapse
Many thanks for the feedback.
Everything I know about Android has been learned from internet research and tutorials. So as far as I can I like to then re-share the things I have learned in way that I understand in the hope it will in turn help others!

wilskywalker said:
Many thanks for the feedback.
Everything I know about Android has been learned from internet research and tutorials. So as far as I can I like to then re-share the things I have learned in way that I understand in the hope it will in turn help others!
Click to expand...
Click to collapse
Me too. What I've been doing is opening other people's flashable .zips and making changes that I needed to make so I can flash what I wanted to flash. I have something that I want to change in a ROM I've been helping to work on, and your guide will help in the setup process.

dsmryder said:
Me too. What I've been doing is opening other people's flashable .zips and making changes that I needed to make so I can flash what I wanted to flash. I have something that I want to change in a ROM I've been helping to work on, and your guide will help in the setup process.
Click to expand...
Click to collapse
Glad my guide helped out buddy! This community has helped me to learn so much, it's nice to give something back.

I'm looking to create a script that deletes system apps/sounds I don't want upon updating CM9 (nightly). I've taken a script from a different device and modified, what I hope is, accordingly. I only edited the mounts to: ext4 /dev/block/platform/omap/omap_hsmmc.0/by-name /system and of course the apps I want to delete upon first boot. Edit removed the detailed path as per someone's advice.
Does this look like it will accomplish my objective?
Edit: Annnnnnnd it doesn't.
Code:
#!/system/bin/sh
#mount system rw
mount -o remount, rw -t /system
#apps to delete
#send installed apps to /data/packages
pm list packages -f > /data/packages
for i in HoloSpiralWallpaper LiveWallpapers LiveWallpapersPicker MagicSmokeWallpapers Music PhaseBeam RomManager VisualizationWallpapers
do
if [ -e /system/app/$i.apk ]
then
rm -f /system/app/$i.apk
grep $i.apk /data/packages > /data/pname
pname2=$(sed 's/\(.*=\)\(.*\)/\2/' /data/pname)
pm uninstall $pname2
fi
done
rm -f /data/packages
rm -f /data/pname
#delete camera_click sound
if [ -e /system/media/audio/ui/camera_click.ogg ]
then
rm -f /system/media/audio/ui/camera_click.ogg
fi
#delete camera_focus sound
if [ -e /system/media/audio/ui/camera_focus.ogg ]
then
rm -f /system/media/audio/ui/camera_focus.ogg
fi
#mount system ro
mount -o remount,ro -t /system
Source: http://forum.xda-developers.com/showthread.php?t=1050288

CMNein said:
I'm looking to create a script that deletes system apps/sounds I don't want upon updating CM9 (nightly). I've taken a script from a different device and modified, what I hope is, accordingly. I only edited the mounts to: ext4 /dev/block/platform/omap/omap_hsmmc.0/by-name /system and of course the apps I want to delete upon first boot. Edit removed the detailed path as per someone's advice.
Does this look like it will accomplish my objective?
Edit: Annnnnnnd it doesn't.
Code:
#!/system/bin/sh
#mount system rw
mount -o remount, rw -t /system
#apps to delete
#send installed apps to /data/packages
pm list packages -f > /data/packages
for i in HoloSpiralWallpaper LiveWallpapers LiveWallpapersPicker MagicSmokeWallpapers Music PhaseBeam RomManager VisualizationWallpapers
do
if [ -e /system/app/$i.apk ]
then
rm -f /system/app/$i.apk
grep $i.apk /data/packages > /data/pname
pname2=$(sed 's/\(.*=\)\(.*\)/\2/' /data/pname)
pm uninstall $pname2
fi
done
rm -f /data/packages
rm -f /data/pname
#delete camera_click sound
if [ -e /system/media/audio/ui/camera_click.ogg ]
then
rm -f /system/media/audio/ui/camera_click.ogg
fi
#delete camera_focus sound
if [ -e /system/media/audio/ui/camera_focus.ogg ]
then
rm -f /system/media/audio/ui/camera_focus.ogg
fi
#mount system ro
mount -o remount,ro -t /system
Source: http://forum.xda-developers.com/showthread.php?t=1050288
Click to expand...
Click to collapse
Hey buddy,
This looks like an init.d script to me, this is different to Edify. init.d scripts are placed in the /system/etc/init.d folder and performs actions when you boot the phone.
Your post has piqued my interest in init.d scripting though, might have to make it my next thing to learn!

wilskywalker said:
Hey buddy,
This looks like an init.d script to me, this is different to Edify. init.d scripts are placed in the /system/etc/init.d folder and performs actions when you boot the phone.
Your post has piqued my interest in init.d scripting though, might have to make it my next thing to learn!
Click to expand...
Click to collapse
Yes init.d, wasn't sure if you'd have insight or not, but glad to have piqued your interest
Sent from my Galaxy Nexus

CMNein said:
Yes init.d, wasn't sure if you'd have insight or not, but glad to have piqued your interest
Click to expand...
Click to collapse
Sorry I couldn't help more buddy.
Interest definitely piqued though...only problem is that I am currently trying to teach myself HTML5, C++ and Edify as well...lol!
Whenever I am working on a particular project I always get sidetracked and end up trying to learn a whole new language...the only reason I started investigating Edify was so I could flash bootanimations and that led to this tutorial!

Hi, I just recently set out to teach myself making flashable zips and this was one of the more helpful guides that I found. Especially helps that it's for my phone, which eliminates a good chunk of confusion, and that it's recent, since a lot of guides that I've found seem to be a bit outdated.
However, you don't say anything about setting permissions and that's the topic that I've had the most trouble finding clear documentation for. I see it included enough that I figure that it's good practice to cover any time you're pushing files with a flash, instead of just assuming that you can run fix permissions afterwards out of habit. Without a background working with linux permissions this was all a lot to absorb, and googling terms was frustratingly unhelpful, but hopefully this goes on to help someone else.
Syntax:
Code:
set_perm (UID, GID, MODE, "PATH");
set_perm_recursive(UID, GID, DIRMODE, FILEMODE, "PATH");
So, I think I get this, but the UID and GID aspects, and the leading digit of mode still leaves me feeling like I can do this right, but not fully understand why. Here's what I'm working with:
-UID and GID set the ownership of the file/directory. List of options in android found here:
http://android-dls.com/wiki/index.php?title=Android_UIDs_and_GIDs
I've only ever seen this specified as 0 (root access) or 1000 (system access) in examples I've opened to look at. I'm not sure I entirely understand when to use 1000, but it seems like a good rule of thumb that pushing anything to a dir that usually requires root to access, set to 0.
-MODE is summed up nicely here, and it seems like for the most part you want to use a leading 0, or omit it (leave settings as is).
-And then path is just the file or directory in question. Multiple paths can be specified in the same command if desired.
So in general, a zip that pushes a file to an existing directory should include a line in the installer-script that sets the right permissions. Android seems to keep things pretty simple, so chances are you can browse to the directory and just check the permissions for anything there and use them. For example, everything in /system/app is set to rw-r--r--, which is 644. So if you wanted to push a file to /system/app, you'd use this:
Code:
set_perm (0, 0, 0644, "/system/app/[filename]");
.
If you are pushing multiple files to /system/app, you could use this:
Code:
set_perm (0, 0, 0644 "/system/app/[filename1]", "system/app/[filename2]");
Edit: I'm not sure I see an easy way to use set_perm_recursive to just cover all bases unless you're dealing with a folder that you know has only one uniform permission setting across the board (such as /system/app or /data/app). But if you're pushing a bunch of system apps, for example, you could use this:
Code:
set_perm_recursive (0, 0, 0755, 0644 "/system/app");
and it should have the same effect on the /system/app folder as just running fix permissions in recovery would do.
If I have anything wrong here please let me know. Gonna go tinker with it and try to make a working zip now as a test.

JoeSyr said:
Hi, I just recently set out to teach myself making flashable zips and this was one of the more helpful guides that I found. Especially helps that it's for my phone, which eliminates a good chunk of confusion, and that it's recent, since a lot of guides that I've found seem to be a bit outdated.
However, you don't say anything about setting permissions and that's the topic that I've had the most trouble finding clear documentation for...
...If I have anything wrong here please let me know. Gonna go tinker with it and try to make a working zip now as a test.
Click to expand...
Click to collapse
Ahh, permissions, this is my next set of commands in post #2. I really don't understand the whole permissions thing currently, so was having trouble writing it in simple terms for all to understand...if that makes sense!?
If you are happy, I would like to include your findings in the second post with all the commands (I may re-word/re-order etc for clarity as we learn more) I will of course credit you for all your help!?
I am literally trying to learn about setting permissions currently as well so its great to collaborate, this was what I was hoping for when I started this tutorial.

Ok, I have been researching Android file permissions and commands all afternoon, there really is not much documentation to be found.
I have found the info I think I need to add this to my tutorial, just need to make sense of it myself first and put it in some sort of understandable order!
Big update coming soon...

wilskywalker said:
Ahh, permissions, this is my next set of commands in post #2. I really don't understand the whole permissions thing currently, so was having trouble writing it in simple terms for all to understand...if that makes sense!?
If you are happy, I would like to include your findings in the second post with all the commands (I may re-word/re-order etc for clarity as we learn more) I will of course credit you for all your help!?
I am literally trying to learn about setting permissions currently as well so its great to collaborate, this was what I was hoping for when I started this tutorial.
Click to expand...
Click to collapse
Yes by all means feel copy and/or adapt anything I've written, and if I give the impression that I know what I'm talking about I'm happy to try and explain things as well.
I'll let you decide for yourself how much of an explanation you want to include in your guide, personally I'm going through and teaching myself a lot here, but I think I've just about figured out what you *need to know* to use the set_perm function in edify. You basically need one tool and the ability to do basic math in your head:
-Use Root Explorer to find the UID, GID, and permissions for a file. Permissions are the string that looks like some variation on 'rwxr-xr--' next to each file. Long press and choose "change owner" to get the UID and GID. You just want the number next to "owner" and "group", respectively.
-If you're replacing a file, look up these settings for the existing copy and use them. If you're adding a file, just find a file that does the same functions and copy what it has (for example, installing an app to /system/app? Just look at these settings for any other app in that directory).
-The permission string is a nine-character string. It is rwx repeated three times, each of which stands for one number. Within each rwx block, read r as 4, w as 2, and x as 1. A dash indicates 0 instead of whichever number. So, learn to read rwxrwxrwx as (4+2+1)|(4+2+1)|(4+2+1)=777; rwxr-xr-- is (4+2+1)|(4+0+1)|(4+0+0)=754, etc. This is what you enter for MODE, with one additional note:
-MODE is technically a 4-bit string, but the first bit is special and can be omitted. I've looked around, and have yet to find a single file on my phone that has anything set for the first bit. For good practice, I think it's safe to assume you can always use a leading 0 unless you know otherwise for something specific. Or, just use a 3-digit MODE, which says to leave those settings as they are (disabled by default). (I.e. 0644=644).
As another note, I personally use ES File Explorer w/ root access in my day-to-day tasks because I like the interface, but it will not give you UID or GID, or let you chance these settings.
For really understanding why this is all done this way, I think it helps to really get a grasp for why linux permissions work the way that they do (read this page) and how they are manipulated (this page). Then, consider that a lot of that is built on the assumption that there are multiple humans in the same environment, but android is built on the premise of one person and their phone. Security is largely reduced to limiting the abilities of apps (which all get their own user id, as though apps are a bunch of people signing into computers and trying to look at each others' files). Groups are pre-defined here, and the usual setup is that apps get to effectively request group permissions when installed, otherwise most things in userland don't get access to much other than writing and reading the sdcard.
Sort of makes you appreciate the work done to get phones rooted and turn them from a pallet of pre-defined actions set by OEMs into real computers.

wilskywalker said:
...
Format a partition:
To format a partition you need to use the following syntax:
Code:
format("filesystem-type", "partition-type", "device-specific-location", "0");
Example:
Code:
format("ext4", "EMMC", "/dev/block/platform/omap/omap_hsmmc.0/by-name/system", "0");
Some scripts include the "0" and some do not, not sure exactly on the function difference when included or not, again clarification would be great.
...
Click to expand...
Click to collapse
How to format boot? There is no that menu in CWM and TWRP

[Root] [Script] OTA Killer for LG K7 m1 and other devices

Disclaimer: I nor XDA nor anyone else is responsible for your lack of reading or comprehension skills, ignorance on your part or anyone else's nor just plain stupidity on your part or anyone else's, so if you don't know what you're doing and or don't know how to fix any bad things that could happen then just don't do it.
Root and Busybox required.
This is a more permanent solution to stop OTA updates from downloading on your rooted device that is designed to survive when you wipe /cache. I'm including the script which will work on any device that downloads it's OTA updates as update.zip to /cache without modification and a flashable zip, the flashable zip is for the LG K7 m1 Metro PCS variant rooted with Magisk ONLY (unless modified) and was fully tested, you're free to edit the script and or the updater-script in the flashable zip for your device (be sure you get the /system partition for your device right, the init process right if not rooted with Magisk and the proper location and file name for your OTA updates) and you may release it for others to use if you like but please give appropriate credit. The script can simply be dropped in your appropriate init folder (/data/adb/service.d/ for Magisk) and set chmod 0700 before rebooting your device.
Alternately you can use MacroDroid to run the script at boot.
Trigger > Device Events > Device Boot
Action > Applications > Shell Script (Paste script on line)
The rest should be self-explanatory.
Thanks to QuickNET Tech for coming up with this method. You can and should read about it HERE and follow up with part 3 from their post so you don't get the annoying notifications. Instructions for reversing this modification are also in that thread, in addition to those instructions you'll also need to delete the 22otakiller script from your init directory (default is /data/adb/service.d/).
QuickNET Tech said:
-Part 3. [Optional]
The annoying update notifications are actually Google Play Services fault. All you have to do is go to "Settings > Apps" and find Google play services and disable the apps ability to show you notifications.
Click to expand...
Click to collapse
What this script does:
The script (see bottom of this post) when ran either automatically on boot or manually will check for update.zip in /cache, if it exist but wasn't created by the script or using the same method with the appropriate attribute applied then it will delete it (regardless of size including an authentic update.zip file) and create the appropriate 0 byte update.zip file with the appropriate attribute and permissions, if it doesn't exist it will create the appropriate file with the appropriate attribute and permissions. It creates a 0 byte update.zip that can not be modified or deleted by anyone including the super user without removing the file attribute which can only be removed by the super user. The flashable zip for the LG K7 rooted with Magisk ONLY (unless edited for your device and or root method) will install the script to /data/adb/service.d/ and set it's permissions to 0700.
Please let me know and post your device information if the updater-script in the flashable zip works as-is with your device.
Enjoy!
Script (22otakiller):
Code:
#!/system/bin/sh
uzip="/cache/update.zip"
if [ -f "$uzip" ] && lsattr "$uzip" | cut -c 6 | fgrep -q 'i'
then
exit
elif [ -f "$uzip" ]
then
rm -f $uzip
touch $uzip
chmod 7400 $uzip
chattr +i $uzip
exit
else
touch $uzip
chmod 7400 $uzip
chattr +i $uzip
exit
fi

Been a long time since I've been on this site seeing as most every device after the K7 hasn't had any development. Glad to see people are still messing with this device. Good work man!

Substratum not working

I have substratum working on 2 other modded moto devices but can't get it to work on this XT1952-4. I am running Descendant-4.0.1_a64_ab Pie. The substratum version is one thousand twenty two. My device is successfuly rooted using @Spaceminer modded phh root. I have Magisk on the other 2 devices. If anyone has any ideas on this I would appreciate it. Thanks

Motomizer said:
I have substratum working on 2 other modded moto devices but can't get it to work on this XT1952-4. I am running Descendant-4.0.1_a64_ab Pie. The substratum version is one thousand twenty two. My device is successfuly rooted using @Spaceminer modded phh root. I have Magisk on the other 2 devices. If anyone has any ideas on this I would appreciate it. Thanks
Click to expand...
Click to collapse
I think that I have a solution if you can run a command from termux or adb for me.
Code:
ls /system/bin | grep .sh
Give me the output of that. I'll probably need you to send me a file afterwards, but I need to get the name of it first. I'll recognize it when I see it. If you get a special character error, drop the dot off of sh.

Wow, I wasn't expecting the legend himself replying. I don't have termux so I will get on the computer and do adb

It says cannot access '/system/bin'

I installed termux and got the following result:
crash_dump32
lshal
phh-on-boot.sh
rw-system.sh
twrp.sh

Motomizer said:
I installed termux and got the following result:
crash_dump32
lshal
phh-on-boot.sh
rw-system.sh
twrp.sh
Click to expand...
Click to collapse
Rename phh-on-boot.sh to phh-on-boot.txt and send it to me. Use the paperclip to attach it. Use a root explorer to copy it to your sdcard first. Or from termux...
Code:
su
cp /system/bin/phh-on-boot.sh /sdcard/phh-on-boot.sh
You can also concatenate it and pipe the output to a text file like this...
Code:
su
cat /system/bin/phh-on-boot.sh > /sdcard/phh-on-boot.txt

Spaceminer said:
Rename phh-on-boot.sh to phh-on-boot.txt and send it to me. Use the paperclip to attach it. Use a root explorer to copy it to your sdcard first. Or from termux...
Code:
su
cp /system/bin/phh-on-boot.sh /sdcard/phh-on-boot.sh
You can also concatenate it and pipe the output to a text file like this...
Code:
su
cat /system/bin/phh-on-boot.sh > /sdcard/phh-on-boot.txt
Click to expand...
Click to collapse
Ok, I copied and renamed the file easily with a file manager. I can't find a paperclip symbol anywhere to attach it. Is there a post quota to allow attachments?

Motomizer said:
Ok, I copied and renamed the file easily with a file manager. I can't find a paperclip symbol anywhere to attach it. Is there a post quota to allow attachments?
Click to expand...
Click to collapse
I believe there is a quota. 10 if I'm not mistaken. Just use the code button "#" and paste the text of it in a reply.

Spaceminer said:
I believe there is a quota. 10 if I'm not mistaken. Just use the code button "#" and paste the text of it in a reply.
Click to expand...
Click to collapse
[#!/system/bin/sh
[ "$(getprop vold.decrypt)" = "trigger_restart_min_framework" ] && exit 0
if [ -f /vendor/bin/mtkmal ];then
if [ "$(getprop persist.mtk_ims_support)" = 1 ] || [ "$(getprop persist.mtk_epdg_support)" = 1 ];then
setprop persist.mtk_ims_support 0
setprop persist.mtk_epdg_support 0
reboot
fi
fi
#Clear looping services
sleep 30
getprop | \
grep restarting | \
sed -nE -e 's/\[([^]]*).*/\1/g' -e 's/init.svc.(.*)/\1/p' |
while read -r svc ;do
setprop ctl.stop "$svc"
done
if grep -qF android.hardware.boot /vendor/manifest.xml || grep -qF android.hardware.boot /vendor/etc/vintf/manifest.xml ;then
bootctl mark-boot-successful
fi
]

Motomizer said:
[#!/system/bin/sh
[ "$(getprop vold.decrypt)" = "trigger_restart_min_framework" ] && exit 0
if [ -f /vendor/bin/mtkmal ];then
if [ "$(getprop persist.mtk_ims_support)" = 1 ] || [ "$(getprop persist.mtk_epdg_support)" = 1 ];then
setprop persist.mtk_ims_support 0
setprop persist.mtk_epdg_support 0
reboot
fi
fi
#Clear looping services
sleep 30
getprop | \
grep restarting | \
sed -nE -e 's/\[([^]]*).*/\1/g' -e 's/init.svc.(.*)/\1/p' |
while read -r svc ;do
setprop ctl.stop "$svc"
done
if grep -qF android.hardware.boot /vendor/manifest.xml || grep -qF android.hardware.boot /vendor/etc/vintf/manifest.xml ;then
bootctl mark-boot-successful
fi
]
Click to expand...
Click to collapse
Try this and see if it works. Place the file on your internal storage, then open up termux and run the following commands.
Code:
mount -o remount,rw /
mv /sdcard/phh-on-boot.txt /sdcard/phh-on-boot.sh
cp -f /sdcard/phh-on-boot.sh /system/bin
chmod 0755 /system/bin/phh-on-boot.sh
reboot
After rebooting, see if substratum will work.
For future reference, the code brackets work like so on XDA...
Code:
The text goes here...[/CODE ← Close this with another bracket. "]"
[CODE]The text goes here...
The bracket was closed, so now it looks different.
This helps formatting when working with scripts.

Spaceminer said:
Try this and see if it works. Place the file on your internal storage, then open up termux and run the following commands.
Code:
mount -o remount,rw /
mv /sdcard/phh-on-boot.txt /sdcard/phh-on-boot.sh
cp -f /sdcard/phh-on-boot.sh /system/bin
chmod 0755 /system/bin/phh-on-boot.sh
reboot
After rebooting, see if substratum will work.
For future reference, the code brackets work like so on XDA...
Code:
The text goes here...[/CODE ← Close this with another bracket. "]"
[CODE]The text goes here...
The bracket was closed, so now it looks different.
This helps formatting when working with scripts.
Click to expand...
Click to collapse
I knew that file I sent you didn't look right, but didn't know how to fix it. Thanks for the code bracket lesson and your patience. Unfortunately the code you had me run in termux didn't get substratum working. So you know, when I first ran into problems on this g7 play I copied the substratum apk over to my z play to see if the package was corrupt but it works fine there. Same with the themes.

Motomizer said:
I knew that file I sent you didn't look right, but didn't know how to fix it. Thanks for the code bracket lesson and your patience. Unfortunately the code you had me run in termux didn't get substratum working. So you know, when I first ran into problems on this g7 play I copied the substratum apk over to my z play to see if the package was corrupt but it works fine there. Same with the themes.
Click to expand...
Click to collapse
Can you check the build number on substratum? Find it in your app list and check near the bottom of it's info. Should look something like the attached screenshot. I'll see what I can dig up about it.

Spaceminer said:
Can you check the build number on substratum? Find it in your app list and check near the bottom of it's info. Should look something like the attached screenshot. I'll see what I can dig up about it.
Click to expand...
Click to collapse
I was trying to send a screenshot of the app info but I guess I can't do that yet, either. Next to the i in a circle at the bottom it reads:
version one thousand twenty two
They spell it out instead of using numerical digits. I have seen it like that even on older versions.
There is more information at ApkMirror. It's even compatible with Android 10. I didn't know that.

@Spaceminer
Could it be that Descendant-4.0.1_a64_ab Pie doesn't have OMS support? I did a full xda search on that and got no results. When I have time I will install another gsi rom and see what happens.

Motomizer said:
@Spaceminer
Could it be that Descendant-4.0.1_a64_ab Pie doesn't have OMS support? I did a full xda search on that and got no results. When I have time I will install another gsi rom and see what happens.
Click to expand...
Click to collapse
It's been quite awhile since I've tested descendant. That could be the case but I doubt it. OMS should be baked into the source code. I have been wrong before though. I'll see what I can find about that.

Spaceminer said:
It's been quite awhile since I've tested descendant. That could be the case but I doubt it. OMS should be baked into the source code. I have been wrong before though. I'll see what I can find about that.
Click to expand...
Click to collapse
I was just at the descendant telegram group and asked about OMS support. Dil3mma4 himself answered and said that they never really cared about substratum, nor do they now.

Motomizer said:
I was just at the descendant telegram group and asked about OMS support. Dil3mma4 himself answered and said that they never really cared about substratum, nor do they now.
Click to expand...
Click to collapse
I think this is the answer. It looks like it's unsupported.