I'm trying to implement a Power Menu mod for the SGS4G but I'm running into trouble with Globalactions.smali from Android.Policy.jar. I've been using this guide: http://forum.xda-developers.com/showthread.php?t=811532&highlight=power+menu+mod which was written for the Vibrant and just been adapting it to the SGS4G but I can't even figure out how to adapt it to the Globalactions.smali file.
Could anyone give me a hand? here's the smali file:
http://dl.dropbox.com/u/12235402/GlobalActions.smali
Thanks.
I'm no expert, but I put together these basic instructions for someone else, maybe it will help you....this was specific for the 4n1 power mod
-download patch file: http://forum.xda-developers.com/showpost.php?p=8324212&postcount=2
-deodex android.policy.jar
-open deodexed android.policy.jar w/ 7zip, extract classes.dex
-decompile classes.dex (java -jar baksmali.jar classes.dex)
-make changes per patch file (Baksmali\out\com\android\internal\policy\impl)
-copy folder to smali dir
-compile classes.dex (java -jar smali.jar -o classes.dex out/)
for the icon:
-decompile com.htc.resourses using apktool, (apktool d com.htc.resourses.apk)
-navigate to apktool\com.htc.resources\res\drawable-hdpi & choose an icon, copy it's name
-navigate to apktool\com.htc.resources\res\values\public.xml, search for the icon name
-copy icon hex value, ie... 0x020200d5, omitting the 0x0, making it 20200d5
-open Baksmali\out\com\android\internal\policy\impl\GlobalActions.smali
-search for original icon (20200d9), change to 20200d5
-copy folder to smali dir
-compile classes.dex (java -jar smali.jar -o classes.dex out/)
Related
Adapted from http://zezke.xtreemhost.com/2010/9/black-android-status-bar/
This is just a brief guide. The steps are a little different for the XT720. This was tested on a XT720 using Dexter's Froyo 1.2a.
Getting started
Tools needed: apktool, android sdk, java jre, 7zip/winrar/etc, smali.jar and baksmali.jar
Changing the theme
adb pull /system/framework/framework-res.apk framework-res.apk
java -jar "apktool.jar" d -f framework-res.apk
Navigate to framework-res/res folder.
Here, the drawable-hdpi folder contains the images for the theme. You can either replace the images in here with images from another theme (easier, but might not always work) or modify the images yourself (complicated).
Changing the status bar colour
What you want is the status_bar.xml file in the layout folder.
Look for
Code:
<com.android.server.status.DateView android:textSize="16.0sp" android:textStyle="bold" android:textColor="#ffffffff" android:gravity="left|center" android:id="@id/date" android:background="@drawable/statusbar_background" android:paddingLeft="6.0px" android:paddingRight="6.0px" android:layout_width="wrap_content" android:layout_height="fill_parent" android:singleLine="true" />
near the end of the file.
To change the colour, change the value of the attribute android:textColor. For mine, I changed it to android:textColor="#ffffffff". This is in hexadecimal. The first two letters dictate the transparency. The rest is just the standard RGB hex code. For example, black is #ff000000. Full transparency is #00ffffff.
After making the modifications, you have to repack.
java -jar apktool.jar b "framework-res"
You'll find your new framework-res.apk in framework-res/dist.
P.S. Replacing the original framework-res.apk with the new one didn't work for me. I have to make a Metamorph theme and apply it. Coming to that in a moment.
Changing the clock colour
adb pull /system/framework/services.jar services.jar
Open services.jar (using 7zip) and extract classes.dex (only). Get smali.jar and baksmali.jar from Google Code (latest version when writing this guide 1.2.4).
java -Xmx512M -jar baksmali.jar -o classout classes.dex
This will create a directory named classout in your current working directory. Open it and go to com/android/server/status and open (using a text editor) StatusBarIcon.smali. Look for this fragment:
.line 60
const/high16 v6, -0x100
invoke-virtual {v4, v6}, Landroid/widget/TextView;->setTextColor(I)V
I think the important thing is the setTextColor(I)V. The .line60 may differ for most phones.
Now, the original colour is the line
const/high16 v6, -0x100
change it into
const v6, -0x1
for white.
Then save it.
I'm not sure what the other colour codes are, but I think you can find out with a search.
Now return to the folder containing services.jar and classes.dex. Rename classes.dex as classes.dex.backup just to be safe and have a backup. Recreate the dexfile:
java -Xmx512M -jar smali.jar classout -o classes.dex
Add the new classes.dex file to the services.jar (crucial that you add it instead of creating a new archive).
---Making Metamorphs
It's easier if you just use my Metamorph as a template.
http://forum.xda-developers.com/showthread.php?t=955698
In my Metamorph theme, replace the framework/services.jar with yours.
The framework-res/res folder contains files to replace in the system's framework-res.apk. Empty the folder, then extract files that you have changed from your new framework-res.apk(using 7zip/etc, this is important) and put them in this folder.
You can change the owq.xml file.
<item>framework-res.apk</item>
<path>/system/framework/</path>
Means that files in the archive /system/framework/framework-res.apk will be replaced with the ones in the Metamorph theme folder /framework-res
<item>framework.cpy</item>
<path>/system/framework/</path>
Means that files in /framework will be copied to /system/framework/, replacing any existing files. (Due to the .cpy extension, short for copy)
thanks for the tutorial
I've been looking everywhere all weekend for this. Where do i locate the lockscreen slider image in order to replace with a custom one? looked all through internal memory and i know it's in a .apk file but which one? i hope somebody can help me with this, thanks in advance.
you have to pull the framework-res.apk file. You also have to be rooted to do this. It should be in system/framework
That should be in /system/framework/framework-res.apk. Once you get that you will need to decompile it with a program like apk Manager, edit the draw-9 pngs, then recompile it with apk Manager.
The reason that you should decompile it is that the lockscreen images that you want to edit are draw-9 png images. Draw-9 pngs are resizable by the system because they have an outer border on all images that tell it how to stretch. When you simply extract them from the framework-res.png, with a program like winzip, they lose that outer border. You need to decompile them in order to maintain that border when you edit them. Recompile them afterwards and then you can put that framework-res.apk on the phone with the new lockscreen.
Download apk Manager
Now here is what I've learned about apk Manager:
put framework-res.apk in the place-apk-here-for-modding folder
run the script
enter 22 to select an apk, then 1 to select your apk
press 9 to decompile the apk
go into the projects/framework-res.apk/res/drawable-hdpi folder and edit your pngs (maintain the border)
go back to the script once your done editing and enter 11 to compile
when asked if it is a system apk enter y
when asked if you want to extract other files too enter y
go into the keep folder that was created and delete any pngs that you changed in the projects folder
if you change any xml files, you will also need to delete the resources.arsc file from the keep folder
go back to the script and press any key to continue
your recompiled framework-res will be in the place-apk-here-for-modding as unsigned-framework-res.apk
extract unsigned-framework-res.apk using winzip, or similar program (this is being it is compressed incorrectly)
go into the folder where you just unzipped the framework and zip it up with the compression mode set to Store - call it framework-res.apk
you are ready to go with a properly editing framework-res.apk, put it on your phone any way you like
Make sure that you have no errors when de-compiling or re-compiling. It might seem like everything is going ok, but you could end up soft bricking your phone if you don't check the log.txt in the apk Manager main folder. Check the log.txt after every decompile and recompile to ensure that you don't have a damaged framework-res.apk.
The output in log.txt should like like this for a proper decompile:
Code:
--------------------------------------------------------------------------
|Sun 05/01/2011 -- 20:11:47.57|
--------------------------------------------------------------------------
java version "1.6.0_25"
Java(TM) SE Runtime Environment (build 1.6.0_25-b06)
Java HotSpot(TM) 64-Bit Server VM (build 20.0-b11, mixed mode)
Could Not Find C:\Users\jbush\Documents\Custom Atrix\Programs\apk_manager_4.9\place-apk-here-for-modding\../place-apk-here-for-modding/signedframework-res.apk
I: Loading resource table...
I: Decoding resources...
I: Copying assets and libs...
And like this for a proper recompile:
Code:
W: Could not find sources
I: Checking whether resources has changed...
I: Building resources...
I: Building apk file...
(skipping index file 'C:\Users\jbush\Documents\Custom Atrix\Programs\apk_manager_4.9\other\..\projects\framework-res.apk\assets\images\Thumbs.db')
(skipping index file 'C:\Users\jbush\Documents\Custom Atrix\Programs\apk_manager_4.9\other\..\projects\framework-res.apk\assets\webkit\Thumbs.db')
The system cannot find the file specified.
If you get any errors about your images then you need to fix them before you can recompile.
thanks, gettin to work on it now.
Replace lockscreen image
I did not use any special software for this. Just copied (using Root explorer on device) file \system\framework\framework-res.apk to sdcard, then easily copied it to PC desktop. Opened the file with Winzip, extracted image zzzzzzzz_default_lockscreenw.jpg (may be the image name is different on your device, so it's better you preview it in order to compare with your lockscreen image) just to notice the image size. Removed the image from apk. Without closing the winzip window I made an image of the same size and name. Then I dragged it inside the Winzip window. Then used reverse steps to put it back in \system\framework.
That's it!
I don't want to use APK Multi-Tools or APK_Manager or whatever. I want to know exactly what those tools are doing in order to recompile the system apk while keeping the original signature.
What I initially did...
Code:
apktool d "%~dpnx1.apk" "%~dpnx1"
...modify files here...
apktool b "%~dpnx1" "%~dpnx1.apk"
But obviously that's unsigned. I need to sign it, but I want to use the original signature, which I'm guessing is the META-INF stuff, right?
So I attempted this...
Code:
apktool d "%~dpnx1.apk" "%~dpnx1"
7za x -o"%~dpnx1-signature" "%~dpnx1.apk" META-INF -r
...modify files here...
apktool b "%~dpnx1" "%~dpnx1.apk"
7za a -tzip "%~dpnx1.apk" "%~dpnx1-signature/*" -mx9
You'll notice I now use 7-Zip to pull out META-INF from the original APK and then insert it back into the recompiled one afterwards.
The only other thing I can think of would be to go with my first method, but then use 7-zip to pull out the compiled files from the unsigned apk and insert them into the signed apk. I haven't tried that yet, but it will be the next one I go with. Every time this fails, though, I have to do a nandroid restore, and it's getting a little frustrating, which is why I'm asking you folks.
--
edit: I got it all figured out.
For those interested, after running "apktool b" (to build/compile), ignore the output zip. Instead go into the source directory and there is now a build directory. In that is an apk directory. Simply add your changed files to the original untouched APK (if you modified any XML files, then replace resources.arsc; if you added anything to smali, then replace classes.dex; if you added any XML files, then you need to include those as well; for me, i copied resources.arsc, classes.dex, and one new XML file). I used the following command:
Code:
zip -9 ..\SystemUI.apk res\layout\status_bar.xml classes.dex resources.arsc
I use zip instead of 7za for cosmetic reasons. You can also use "7za a -tzip etc..." if you want.
hello i know how you feel well....i never did.
you keep a backup and a copy of your system apk and once you did your changes look in your copy and go to /res and delete the destinations you modded and putted them in the modded apk now look into your modded apk file in /res and take the files you deleted from the copy apk and move them to the copy apk and your all set.
if this didnt understand ill show you an awesome thread that will help you
sorry i didnt see your edited section
Hello everyone,
I hope I'm posting this to the right forum.
Up until Android 4.4 KitKat we were able to use apktool for decompiling an apk, making modifications and then recompiling it.
In case we were dealing with an ODEXed ROM, we could also use backsmali and various other tools to deodex before using apktool.
Now, in Lollipop, which uses ART, we get an APK file, but also a .odex file in a '/arm' subfolder.
From what I've read so far, that's not really an odex file, but rather an Android runtime .OAT file.
My question is - how does this affect our abilities to edit APKs?
Is it possible to "deodex" the OAT file to get an all-inclusive APK to use with apktool? If so, how?
After we rebuild the APK, can we just run it 'deodexed' or do we need to recreate an OAT file?
Any insight would be appreciated
purpleman2k said:
Hello everyone,
I hope I'm posting this to the right forum.
Up until Android 4.4 KitKat we were able to use apktool for decompiling an apk, making modifications and then recompiling it.
In case we were dealing with an ODEXed ROM, we could also use backsmali and various other tools to deodex before using apktool.
Now, in Lollipop, which uses ART, we get an APK file, but also a .odex file in a '/arm' subfolder.
From what I've read so far, that's not really an odex file, but rather an Android runtime .OAT file.
My question is - how does this affect our abilities to edit APKs?
Is it possible to "deodex" the OAT file to get an all-inclusive APK to use with apktool? If so, how?
After we rebuild the APK, can we just run it 'deodexed' or do we need to recreate an OAT file?
Any insight would be appreciated
Click to expand...
Click to collapse
Files needed:
1. bootoat2dex.jar
2. Cygwin
3. APKTOOL
4. Java will need to be installed also
Install Cygwin and run it once so your userfolder is created, will be in c:/cygwin/home/<User Name>
Copy bootoat2dex.jar into this folder
Go to priv/app/SystemUI/arm/ and use 7zip to extract SystemUI.odex from the SystemUI.odex.xz file
Copy SystemUI.odex to your cygwin folder c:/cygwin/home/<User Name>/
Open cygwin and run the following command:
java -jar bootoat2dex.jar SystemUI.odex
This will output 2 folders dex and odex, if you look in the odex folder you should see SystemUI.odex.
Rename this file to classes.dex and drop it into the SystemUI.apk file
Follow the same instructions for the twframework-res.odex file also.
now copy the files SystemUI.apk, framework-res.apk and twframework-res.apk into you apktool folder and install framework ex. apktool if framework-res.apk, apktool if SystemUI.apk, apktool if twframework-res.apk
After the framework install you should be able to decompile SystemUI.apk, you should be able to do this with all the apk files.
C13v3r0n3 said:
Files needed:
1. bootoat2dex.jar
2. Cygwin
3. APKTOOL
4. Java will need to be installed also
Install Cygwin and run it once so your userfolder is created, will be in c:/cygwin/home/<User Name>
Copy bootoat2dex.jar into this folder
Go to priv/app/SystemUI/arm/ and use 7zip to extract SystemUI.odex from the SystemUI.odex.xz file
Copy SystemUI.odex to your cygwin folder c:/cygwin/home/<User Name>/
Open cygwin and run the following command:
java -jar bootoat2dex.jar SystemUI.odex
This will output 2 folders dex and odex, if you look in the odex folder you should see SystemUI.odex.
Rename this file to classes.dex and drop it into the SystemUI.apk file
Follow the same instructions for the twframework-res.odex file also.
now copy the files SystemUI.apk, framework-res.apk and twframework-res.apk into you apktool folder and install framework ex. apktool if framework-res.apk, apktool if SystemUI.apk, apktool if twframework-res.apk
After the framework install you should be able to decompile SystemUI.apk, you should be able to do this with all the apk files.
Click to expand...
Click to collapse
Great info! Thanks! I have used oat2dex.py to extract the OAT file, baksmali'd, modified smali code, recompiled it but that's where I'm stuck. How do I get it back into the original OAT format for inclusion in an Odexed rom? Any help would be greatly appreciated.
P.S. I'm working with SystemUI.odex.
jermaine151 said:
Great info! Thanks! I have used oat2dex.py to extract the OAT file, baksmali'd, modified smali code, recompiled it but that's where I'm stuck. How do I get it back into the original OAT format for inclusion in an Odexed rom? Any help would be greatly appreciated.
P.S. I'm working with SystemUI.odex.
Click to expand...
Click to collapse
I haven't been able to find anything that will take the files the other direction.
So I decided to write up a little guide on how to modify apk and jar files on the Axon 7 for those of you who do not know how and would like to make some modifications such as the ones in my guides.
Prerequisites
A Windows/Linux/Mac computer
A rooted device with TWRP Recovery
USB cable
ADB installed and USB debugging enabled
Java JDK: http://www.oracle.com/technetwork/java/javase/downloads/index.html
APKTool: https://ibotpeaches.github.io/Apktool/install/ (Follow all the instructions)
Baksmali: https://bitbucket.org/JesusFreke/smali/downloads/baksmali-2.2.0.jar
7-Zip or another archive manager
1. Install the frameworks to your computer
Open a command window in your working directory and connect your device to your computer with the USB-C cable.
Pull the framework files with
Code:
adb pull /system/framework/framework-res.apk
adb pull /system/framework/framework-zte-res.apk
Install them
Code:
apktool if framework-res.apk
apktool if framework-zte-res.apk
Depending on which ROM you are on you may need to install other frameworks. The above is for the stock ROM.
2. Decompile the apk/jar file.
Pull the apk/jar you want to decompile with
Code:
adb pull path_to_apk_or_jar
Here are paths for some commonly modified apk/jars:
SystemUI: /system/priv-app/SystemUI_ZTE/SystemUI_ZTE.apk
Settings: /system/priv-app/Settings_ZTE/Settings_ZTE.apk
services.jar: /system/framework/services.jar
Decompile the apk with
Code:
apktool d <apk/jar>
If you did everything correctly, a folder should now exist with the name of your apk/jar.
3. Decompile the .odex file
You can skip this step if your apk/jar does not have an .odex associated with it or you only need to modify res and not smali.
Pull the odex file
Code:
adb pull path_to_odex
For example if you want to pull the odex file for SystemUI you would do
Code:
adb pull /system/priv-app/SystemUI_ZTE/oat/arm64/SystemUI_ZTE.odex
Create a folder called "smali" in the directory of your decompiled apk/jar. Then go back to your working directory.
Pull all boot oat files from your device with
Code:
adb pull /system/framework/arm64
Move all the oat files inside the arm64 folder on your PC to your working directory.
Using baksmali, decompile the odex file to smali
Code:
java -jar baksmali.jar deodex -a <api> filename.odex
where api is 23 for Android 6.0, 24 for Android 7.0, and 25 for Android 7.1
A new folder should now be created called "out". Cut and paste the files and folders inside this folder into the "smali" folder you created earlier.
4. Make your modifications.
5. Recompile the apk/jar
From the working directory (not the directory of the decompiled apk/jar) Recompile the apk/jar with
Code:
apktool b name_of_folder
where name_of_folder is the name of the directory of the decompiled apk/jar.
The complied apk/jar should now exist in the "dist" folder in the directory of the decompiled apk/jar.
6. Sign the apk.
Using 7-zip or another archive manager, copy the res folder, resources.arsc file, and the classes.dex file (if you modified smali in steps 3 and 4) from the NEW apk to the ORIGINAL apk.
7. Replace the apk/jar on your device.
Reboot your device into TWRP recovery with
Code:
adb reboot recovery
For user apps: Make sure data is mounted in TWRP's mount menu. If you have encryption turned on you must enter your password otherwise data will not be mounted!
For system apps and framework files: Make sure system is mounted in TWRP's mount menu. Uncheck "Mount system read-only" if it is checked.
Push the ORIGINAL apk/jar to the correct directory on your device
Code:
adb push <apk/jar> path_to_apk_or_jar
Set correct permissions on the apk/jar
Code:
adb shell chmod 0644 path_to_apk_or_jar
If you did step 3, use TWRP's file manager in Advanced<File Manager to navigate to the apk/jar file's directory and delete the existing .oat or .odex file associated with it.
You did it
No go
Hi,
Tried it with the SystemUI_ZTE.apk (and odex) from the 2017G B08 ROM. I ended up with a folder named SystemUI_ZTE. I created a smali folder in that folder and moved the android, com and cn folders (that I got using the "java -jar oat2dex.jar smali SystemUI_ZTE.odex" command) to that smali folder. But when I try the apktool b command I get the following error:
Code:
C:\Users\Blub\ZTE>apktool b SystemUI_ZTE
I: Using Apktool 2.3.0
I: Checking whether sources has changed...
I: Smaling smali folder into classes.dex...
SystemUI_ZTE\smali\android\support\v17\leanback\app\BackgroundManager.smali[102,4] iput-wide-volatile is an odexed instruction. You cannot reassemble a disassembled odex file unless it has been deodexed.
Exception in thread "main" brut.androlib.AndrolibException: Could not smali file: android/support/v17/leanback/app/BackgroundManager.smali
at brut.androlib.src.SmaliBuilder.buildFile(SmaliBuilder.java:75)
at brut.androlib.src.SmaliBuilder.build(SmaliBuilder.java:59)
at brut.androlib.src.SmaliBuilder.build(SmaliBuilder.java:36)
at brut.androlib.Androlib.buildSourcesSmali(Androlib.java:412)
at brut.androlib.Androlib.buildSources(Androlib.java:343)
at brut.androlib.Androlib.build(Androlib.java:299)
at brut.androlib.Androlib.build(Androlib.java:270)
at brut.apktool.Main.cmdBuild(Main.java:224)
at brut.apktool.Main.main(Main.java:75)
Any idea what I am doing wrong?
TIA,
Cheers,
/Cacti
le_cactus said:
Hi,
Tried it with the SystemUI_ZTE.apk (and odex) from the 2017G B08 ROM. I ended up with a folder named SystemUI_ZTE. I created a smali folder in that folder and moved the android, com and cn folders (that I got using the "java -jar oat2dex.jar smali SystemUI_ZTE.odex" command) to that smali folder. But when I try the apktool b command I get the following error:
Any idea what I am doing wrong?
TIA,
Cheers,
/Cacti
Click to expand...
Click to collapse
I updated the OP with a different tool for the odex file. Try it now.
Hi,
Thanks,but "java -jar baksmali-2.2.0.jar -a 25 -x SystemUI_ZTE.odex -d %CD%" gives me this error
Code:
Exception in thread "main" com.beust.jcommander.MissingCommandException: Expected a command, got -a
at com.beust.jcommander.JCommander.parseValues(JCommander.java:725)
at com.beust.jcommander.JCommander.parse(JCommander.java:304)
at com.beust.jcommander.JCommander.parse(JCommander.java:287)
at org.jf.baksmali.Main.main(Main.java:90)
Cheers,
/Cacti
le_cactus said:
Hi,
Thanks,but "java -jar baksmali-2.2.0.jar -a 25 -x SystemUI_ZTE.odex -d %CD%" gives me this error
Cheers,
/Cacti
Click to expand...
Click to collapse
Try it without any arguments: "java -jar baksmali-2.2.0.jar SystemUI_ZTE.odex"
Hi,
The command "java -jar baksmali.jar deodex -a 25 SystemUI_ZTE.odex"gives me
Code:
Error occurred while loading class path files. Aborting.
org.jf.dexlib2.analysis.ClassPathResolver$ResolveException: Error while loading oat file boot.oat
at org.jf.dexlib2.analysis.ClassPathResolver.loadEntry(ClassPathResolver.java:250)
at org.jf.dexlib2.analysis.ClassPathResolver.loadLocalClassPathEntry(ClassPathResolver.java:179)
at org.jf.dexlib2.analysis.ClassPathResolver.loadLocalOrDeviceBootClassPathEntry(ClassPathResolver.java:191)
at org.jf.dexlib2.analysis.ClassPathResolver.<init>(ClassPathResolver.java:120)
at org.jf.dexlib2.analysis.ClassPathResolver.<init>(ClassPathResolver.java:105)
at org.jf.baksmali.AnalysisArguments.loadClassPathForDexFile(AnalysisArguments.java:129)
at org.jf.baksmali.AnalysisArguments.loadClassPathForDexFile(AnalysisArguments.java:86)
at org.jf.baksmali.DisassembleCommand.getOptions(DisassembleCommand.java:203)
at org.jf.baksmali.DeodexCommand.getOptions(DeodexCommand.java:71)
at org.jf.baksmali.DisassembleCommand.run(DisassembleCommand.java:177)
at org.jf.baksmali.Main.main(Main.java:102)
Caused by: org.jf.dexlib2.analysis.ClassPathResolver$NotFoundException: Cannot find dependency boot-core-libart.oat in null
at org.jf.dexlib2.analysis.ClassPathResolver.loadOatDependencies(ClassPathResolver.java:270)
at org.jf.dexlib2.analysis.ClassPathResolver.loadEntry(ClassPathResolver.java:248)
... 10 more
Cheers,
/Cacti
le_cactus said:
Hi,
The command "java -jar baksmali.jar deodex -a 25 SystemUI_ZTE.odex"gives me
Cheers,
/Cacti
Click to expand...
Click to collapse
pull boot-core-libart.oat from /system/framework/arm64/boot-core-libart.oat and try again
Muchas gracias
Hi,
Had to pull all the .oat files from the /system/framework/arm64/ folder, only then I didn't get an error any more using the command "java -jar baksmali.jar deodex -a 25 SystemUI_ZTE.odex". The "command "java -jar baksmali.jar -a 25 -x SystemUI_ZTE.odex -d %CD%" still gave an error, you might wanna change that in the OP.
Now apktool b SystemUI_ZTE didn't give me any errors anymore. Executed the other steps, and bingo! Everthing seems to work. And byy replacing the charging.ogg, my device charges silently.
Thanks from my wife as she now doesn't wake up when I go to bed (and connect the charger). Many thanks for your patience and your excelent guide! I guess I'll bemodding some more APK's now
Cheers,
/Cacti
le_cactus said:
Hi,
Had to pull all the .oat files from the /system/framework/arm64/ folder, only then I didn't get an error any more using the command "java -jar baksmali.jar deodex -a 25 SystemUI_ZTE.odex". The "command "java -jar baksmali.jar -a 25 -x SystemUI_ZTE.odex -d %CD%" still gave an error, you might wanna change that in the OP.
Now apktool b SystemUI_ZTE didn't give me any errors anymore. Executed the other steps, and bingo! Everthing seems to work. And byy replacing the charging.ogg, my device charges silently.
Thanks from my wife as she now doesn't wake up when I go to bed (and connect the charger). Many thanks for your patience and your excelent guide! I guess I'll bemodding some more APK's now
Cheers,
/Cacti
Click to expand...
Click to collapse
Great! I'll add that to the OP! Thanks for helping me out!
Updated the OP with a new signing method that should fix boot hang issues with some apks (aka Settings_ZTE)
bkores said:
Updated the OP with a new signing method that should fix boot hang issues with some apks (aka Settings_ZTE)
Click to expand...
Click to collapse
IMO it was just the same as your previous method (under 5.)was saying : move META-INF ( and manifest but not necessary imo) from original apk into the new apk (in dist folder).
Now you're saying : put res, resources and classes from new apk into new apk...that's just the same, no ? Only more files to move imo.
Since res, resources and classes are indeed changing by compile, wouldn't it be better by just saying : put META-INF from original apk into new apk, like you first wrote in OP ? Easier no ?
ALSO : under 6. you say : Open a command window in the "dist" folder and push the ORIGINAL apk/jar to the correct directory on your device
Shouldn't that be : push ORIGINAL (since you copied files under 5 from NEW(in "dist") to ORIGINAL(in working folder) ) FROM WORKING FOLDER ? Since there is no original apk in DIST folder, only our new apk. Imo you make things a bit confusing here, no ? :cyclops:
raystef66 said:
IMO it was just the same as your previous method (under 5.)was saying : move META-INF ( and manifest but not necessary imo) from original apk into the new apk (in dist folder).
Now you're saying : put res, resources and classes from new apk into new apk...that's just the same, no ? Only more files to move imo.
Since res, resources and classes are indeed changing by compile, wouldn't it be better by just saying : put META-INF from original apk into new apk, like you first wrote in OP ? Easier no ?
ALSO : under 6. you say : Open a command window in the "dist" folder and push the ORIGINAL apk/jar to the correct directory on your device
Shouldn't that be : push ORIGINAL (since you copied files under 5 from NEW(in "dist") to ORIGINAL(in working folder) ) FROM WORKING FOLDER ? Since there is no original apk in DIST folder, only our new apk. Imo you make things a bit confusing here, no ? :cyclops:
Click to expand...
Click to collapse
Fixed!
bkores said:
Fixed!
Click to expand...
Click to collapse
Thnx Mate ! Appreciate all your work :good:
i have some problem with framework.jar, it doesn't have classes.dex in jar but it also doesn't have odex file in /system/framework/oat/arm64 (also arm). Because of it i can't decompile it using smali/baksmali tool. I want to make more volume steps mode like VolumeSteps+ but without Xposed. Hope someone can help.