Hi everyone,
I'm trying to modify Phone.apk 'smali' but am having some difficulties.
What I did so far:
1. Decompiled Phone.apk I pulled from my phone.
2. Modified smali file.
3. Buit it, unzipped, copied original META-INF folder and androidmanifest.xml from unmodified original Phone.apk to my modified Phone.apk
4. Zipped it and pushed to the phone. Got nothing but the "no service". :crying:
Other problems I encountered in the process:
1. When I unzip original Phone.apk and zip it again without modification, I get a different file size than the original no matter what compression method I use.
It worked but force closed on phone call end. (used 7zip). When I zipped (WinRar this time) with no compression (storage only) it worked.
2. I made a tiny modification in 'smali' by defining a new variable (to be sure I didn't mess something up with my mods), built it,
copied META-INF and androidmanifest.xml from the original, and zipped (no compression, storage only, winrar) and it showed 'no service' again.
The phone I used is Samsung Galaxy Advanced (I9070) with Gingerbread Stock ROM.
I tried the described procedure on Samsung Galaxy S (I9000) and it worked.
What am I doing wrong in the process? Please anyone help.
Related
Hallo guys, I trying deodex my rom a week but it did not work as well. Successful only half the rom. Please help me, I have tried many ways to including XUltimate exactly.
Rom here: http://www.mediafire.com/?qj9hllq7cp6uuqj
Sorry for ugly english
What is your phone?
If is an Motorola, here is the tutorial:
Deodexing Explained + How To
So you want to theme… but you keep hearing about all this deodexing stuff… so whats that all about?
Stock android implements an odex file structure; for every (well…most) system app(s) (.apk file) and framework files (.jar) there is a corresponding .odex file, so for example you have;
/system/app/Phone.apk
/system/app/Phone.odex
/system/framework/com.motorola.android.mediasync.jar
/system/framework/com.motorola.android.mediasync.odex
What do the .odex files do?
All of your apps on your device are packaged as .apk files; these files are compiled from google source code and can interchangeably be viewed/thought of as a compressed folder (like a .zip or a .rar); and all of your framework components (well most…) are packaged as .jar files which literally stands for Java Archive (so again this can be compared to a .zip or a .rar).
When the android OS want’s to run your apps or utilize its framework components, it has to parse (read/interpret) the compressed data held within your .apk and/or.jar files. What the odex file structure aims to do, is to expedited this process by utilizing another file (.odex file) to compliment every.apk file (and .jar file); the odex file, includes the most critical data in an uncompressed format so the android os can quickly interpret that important information before parsing through the rest of the data held within the compressed .apk files (and .jar files). So subsequently, in an .odex file structure the .apk & .jar files don’t include all of the applications/framework-components data; Essentially, two files are acting as one; for your apps there are .apk files + their corresponding .odex file and for your framework components there are .jar files + their corresponding .odex file. This works nicely as an optimized file structure, except in the circumstance when the user want’s to theme; theming requires a modification to your .apks; the image files (.pngs) held within the pngs are replaced with different ones. However it is impossible to theme an application if it exists as two files. So that is why it is said you need to be DeOdexed in order to theme; DeOdexing is the process of re-bundling that uncompressed critical data (.odex files) back into your compressed .apk (& .jar) files, so that now all of the data is included in the .apk files necessary to run your applications without the presence of .odex files; in addition all the data is now included within the .jar files necessary to utilize your framework components without .odex files. In a DeOdexed file structure, there are no odex files present.
What are the benefit’s of DeOdexing?
Simple. To be able to theme a stock ROM.
Deodexing doesn’t speed your phone up or do anything of the sort.
It is simply something that is necessary to be able to theme a stock ROM.
How do you DeOdex?
One way you can deodex is to use the application xUltimate which actually rebundles that information for you. Another way, is to use a pre-made DeOdexer Update.zip; this zip already has all the repackaged fully compressed .apk files and utilizes code in the update script to delete all of the odex files present. So essentially all it’s doing is overwriting all your old semi data inclusive .apk files with fully inclusive ones and then deleting the (now) superfluous .odex files. This is the easiest way to do it, since all the work is already done for you. Just flash it in clockwork as you would for any theme:
Download it
Place it on your sdcard
Open Droid X Bootstrap
Hit Bootstrap Recover > Ok > Reboot Recovery
Navigate to ‘Install zip from sdcard’ with volume keys and select with camera button
Navigate to ‘Choose zip from sdcard’ and select
Navigate to the directory containing the above deodexer zip
Select it > Yes
Wait for it to do its thing > reboot system
You are now deodexed.
How can you check to see if you DeOdexed successfully?
Open a file explorer (like Root Explorer or Astro)
Navigate to the directory /system/app
Check for the presence of .odex files
Navigate to the directory /system/framework
Check for the presence of .odex files
If there are no odex files present then you are deodexed!
Now you can theme!
Will DeOdexing slow you down?
Technically it should, but in actuality its really quite negligible to notice, however… In my opinion, it’s rather silly to DeOdex and stay on stock ROM; you should just make the switch to a custom ROM. Why? Because custom ROMs are already deodexed and they zipalign your apps on boot; zipaliging is the process of reorganizing the manner in which the .apk is packaged to optimized it for being parsed faster by the android OS, it is comparable if not better than the odex file structure, so you get the best of both worlds; a themed ROM and the speed of an optimized file structure. That is why Stock is lame and custom ROMS pwn (IMO of course…)
Hi,
I'm trying to figure out why a modified QuickSnote.apk doesn't work on Jelly 'Beans' Rom - Build 4->http://forum.xda-developers.com/showthread.php?t=2032447
This is a problem (for me) because it used to work on build 3 just two days ago.
Here is what I did,
0. Install framework-res.apk, SystemUI.apk, and twframework-res.apk that I extracted from root (build 4)
1. Download and decompile the '/system/app/QuickSnote.apk' using 'apktool'
2. Overwrite QuickSnote/res/raw/popupnote_sound.ogg with a dummy ogg file.
3. Recompile the 'QuickSnote.apk' using 'apktool'
4. Copy&paste jar-res directory from the original apk into newly created apk (it's missing from the new apk for some reason)
5. Sign the apk using 'signapk'
6. Finally, overwrite /system/app/QuickSnote.apk with the new&signed apk
After doing this, I assumed that the only difference in the MANIFEST.MF files would be the SHA1Digest of the 'popupnote_sound.ogg' file. However, many other digests seem to be different.
Could this be the reason why it's not working?
Please assist me with this.
Thanks.
Have you tried to copy :
assets
META-INF
android-manifest.xml
from the original to the new one?
I had same problem with framework-res.apk and it solved it
Hi,
So the situations is like this:
Just got a new LG Nexus 4, NFC enabled, GREAT!!!!
But then I start using it, and the NFC sound (everytime the phone reads a nfc-tag it makes an sound) annoys me beyond belief.
So I start looking around, it seems there's no solution, except recompiling the app.
So I learn how to compile an app (noob here), using this guide: http://forum.xda-developers.com/showthread.php?t=1860115
I'm up to the point where my apk is decompiled, and I have modified the sound files, located in my decompiled files folder respectively at res/raw/start.ogg & res/raw/end.ogg.
I modded the files using audacity, lowering the volume to zero, used them to replace the original .ogg files. The file size is a bit smaller as the original ones (1Kb difference).
Next I use the recompile command: apktool b decompiled_apk_folder_with_modified_files modded_apk_file.apk
So now I have the new nfc apk file, called NfcNci.apk, with which I replace the original file in /system/app.
Next up I reboot my phone into recovery, wipe all cache and dalvik cache, and reboot again.
First thing that pops up on my screen is a force-close message, saying that the nfc-service force closed.
Anyone who can tell me what I did wrong? Or how I can fix this?
Attached are: my decompiled-files-folder (compressed to zip)
the original NfcNci.apk file
my modded NfcNci.apk file which causes the FC's.
Any help will be greatly appreciated!!!!
S.
Looks like you're still on 4.2
The latest NfcNci.apk has some more files.
And your apk is missing the META-INF folder.
I guess that this is the problem.
But you should use "adb logcat" to ensure we're on the right track.
Micky
1 thing i would recomend is not using the actual apk you just built. instead, open your new apk with a file manager such as 7zip and remove your newly compiled files out of it, then put them into the original apk from your rom using 7zip as well! thus keeping the apk's original signature
try to copy the least amount of files from one to another, so to be safe only pull out your new .ogg files, then put them into your original apk! hope this helps
ldrifta said:
1 thing i would recomend is not using the actual apk you just built. instead, open your new apk with a file manager such as 7zip and remove your newly compiled files out of it, then put them into the original apk from your rom using 7zip as well! thus keeping the apk's original signature
try to copy the least amount of files from one to another, so to be safe only pull out your new .ogg files, then put them into your original apk! hope this helps
Click to expand...
Click to collapse
Hi, I tried this, installed 7zip, and double clicked the original apk, I opende the res/raw/ directory, and only copied the files I was using: start.ogg & end.ogg. Then I close 7zip, and send the file to my phone. But as soon as I it them to /system/apps on my phone, and reboot to recovery, wiping the dalvik cache. I get FC's on reboot (NFC-service has FC'd).
Any reasons for this?
Thanks for the help, both of you!
BTW: I'm on Android 4.3 JB
Howdy.
I'm trying to modify a .so file (libflashplayer.so), but have run into a few problems:
I first tried editing the file after it was installed from an .apk. This appears to work at first, but the edited file is quickly replaced with the original.
I then tried editing the file in the .apk package. This causes the package to fail to install (I'm guessing because the md5 in the certificates no longer matches)
Aldo tried moving a folder with the .so files from the .apk (com.adobe.flashplayer-1 which is what is created when the .apk installs correctly) directly into /data/app-lib/.The directory was created successfully but appears to be immediately deleted.
Is there a way to accomplish what I'm trying to do? If so how?
Other possibly relevant info:
My device is rooted
I did not write the code for anything in the .apk, I got it from a link on xda (pretty dubious i know but I couldn't find another option)
I'm using cyanogenmod 10.2 (based on android 4.2 I believe).
I'm editing the file with a hex editor to change a a few characters ("AND" to "WIN")
Hello,
I bought a Umi Diamond X and i just found out that it came with adware.
Since i could not find any custom roms for it, i tried editing the recovery image. Manged to remove some APK files, but SystemUI is giving me some problems.
What I did until now:
1) Used simg2img to convert system.img to a mountable image
2) mounted the previously generated image and deleted suspicious folders from system/app and system/priv-app.
3) Use SPFT to flash the edited image to the device.
However, I found that SystemUI.apk is also making dubious requests in the background, so I need to replace it with a stock version. I tried taking SystemUI.apk from different roms of similar phones, with a similar SoC, and copy-paste it into my edited system.img. However, everytime i do this, SystemUI crashes when the phone starts up.
Going into the stock recovery, i have the option to "check root integraty". This appears to scan (among others) all APK files in system/app and system/priv-app. I see it detects the deleted APKs and the 1 modified APK. Could the installer have a signature of the expected APKs and not install if the file doesn't match that signature?
Is there any way I can replace SystemUI.apk with a known good version?
Bump..
Bump again..