Hi, I'm trying to modify /system/framework/framework-res.apk (on the stock Samsung Oreo ROM), more exactly config_locationProviderPackageNames in res/values/arrays.xml so that I can add org.microg.nlp as location provider. I've used the latest apktool (2.3.4) to unpack and repack the apk. I'm replacing it from TWRP and I checked that it has the same owner and rights. And after rebooting the device never finishes booting up (stuck at Samsung logo and blue led).
If I boot back to recovery and put back the original framework-res.apk the system boots fine.
What else do I need to do to make it accept the modified framework?
hey
Are you ONLY modifying the apk?
I would say there is a lot of things to check. It could be that the apk is being rejected by your handling of it. Compare both versions by 7zip lz4 without extracting. Try and use the best tools during the process.
Also more than likely you're conflicting with a service or permission that a perfect apk can't fix.
Have you tried a search in your ROM to see if any files might be associated with the result you want?
Stuff like...
com.android.location.provider.jar
com.android.location.provider.odex
com.android.location.provider.xml
Try doing all the work from your phone without any windows apps. FX explorer and symlink the apk.
Now that everything I said was probably wrong, someone else can tell you how. I'd try fx and symlink, though. It may just align the planets for you
I'm only modifying one XML resource file, but I don't know what else apktool is doing to the apk.
I'm replacing the original framework-res.apk from TWRP, by cat-ing the modified apk over the original, and I've double checked that the ownership and permissions are unchanged.
I guess I can try using another unpack/repack tool and see if it turns out any better, but I've been told that apktool is as good as it gets.
Perhaps it's because the ROM expects the apk to be signed with a certain key? I don't suppose that the key used by Samsung is available somewhere inside the ROM is it?
wirespot said:
I'm only modifying one XML resource file, but I don't know what else apktool is doing to the apk.
I'm replacing the original framework-res.apk from TWRP, by cat-ing the modified apk over the original, and I've double checked that the ownership and permissions are unchanged.
I guess I can try using another unpack/repack tool and see if it turns out any better, but I've been told that apktool is as good as it gets.
Perhaps it's because the ROM expects the apk to be signed with a certain key? I don't suppose that the key used by Samsung is available somewhere inside the ROM is it?
Click to expand...
Click to collapse
@wirespot - Did you ever solve the problem you described in this thread?
Not really. My last attempt was to use Runtime Resource Overlays (RROs) to override certain framework values in order to allow org.microg.nlp to run side by side with Google's service.
I will provide them below but it ultimately didn't work. The RRO apk was installed correctly, I could access the NLP settings in the system settings but the main app still could not detect or connect to the service and none of the apps that use location would work.
If anybody else wants to build or use the RRO apk I'm attaching the relevant files as well as the apk. Please note that the built apk only has "org.microg.nlp" as service in arrays.xml (but I provide an arrays.xml with all three services).
apktool.yml is provided as txt file because it wouldn't let me upload it otherwise, remove the .txt. It's used if you build the package with apktool. Remember that you'll also have to generate your own certificate and sign the package in order to install it.
Also some links that may help:
https://forum.xda-developers.com/t/guide-how-to-make-gsis-overlay-file-for-your-phone.3878974/
https://github.com/ReinhardStrauch/framework-res-overlay-sample
https://android.stackexchange.com/questions/110927/how-to-mount-system-rewritable-or-read-only-rw-ro
https://source.android.com/devices/architecture/rros#configuring-overlays
https://source.android.com/devices/automotive/hmi/car_ui/appendix
https://source.android.com/devices/automotive/hmi/car_ui/rro#step_6_dump_the_idmap
https://dzone.com/articles/customizing-android-devices-using-the-runtime-reso
https://dzone.com/articles/android-solution-install-parse-1
https://stackoverflow.com/questions...s-not-recognized-internal-or-external-command
https://github.com/lineageos4microg/android_prebuilts_prebuiltapks/issues/22
wirespot said:
I guess I can try using another unpack/repack tool and see if it turns out any better, but I've been told that apktool is as good as it gets.
Click to expand...
Click to collapse
For decompiling and building Android Oreo, I prefer version 2.3.1 of APKTool to other versions of APKTools.
wirespot said:
I'm only modifying one XML resource file, but I don't know what else apktool is doing to the apk.
...
Perhaps it's because the ROM expects the apk to be signed with a certain key? I don't suppose that the key used by Samsung is available somewhere inside the ROM is it?
Click to expand...
Click to collapse
wirespot said:
Hi, I'm trying to modify /system/framework/framework-res.apk (on the stock Samsung Oreo ROM), more exactly config_locationProviderPackageNames in res/values/arrays.xml so that I can add org.microg.nlp as location provider.
What else do I need to do to make it accept the modified framework?
Click to expand...
Click to collapse
I have not tried modifying framework-res.apk of a Samsung Android Oreo nor have I particularly tried the location services mod you are attempting (though I might get around to trying it someday) and do not know if it is valid to to accomplish what you want with it, but believe that the process should be similar to modding the file on LG Android Oreo. I shall try to guide you to how to prepare a framework-res.apk that is proper.
To answer your question about expecting a certain key. The answer to that is that that is usually the case. The signing scheme checks on system apps; however is usually not as thorough as non-system apps. framework-res.apk is also special in that it is not a running app and is instead used as a cache of system resources and system meta information. In the past, before Android Oreo, a rebuilt framework-res.apk may be made to work simply by including original signature files (META-INF) and corresponding AndroidManfest.xml file from the original framework-res.apk into the rebuilt fraemwork-res.apk file. The system would evaluate these files, and pass a check for valid platform signature. With Android Oreo, it appears that there is an additional check that was not present in the past; my best guess is that the system is checking for the V2 signing scheme signing block within the V2 Signing Scheme APK file structure. The check does not, however, thoroughly validate the signing block information.
Your mod seems rather simple and, given your previous posts, would only involve a modification to framework-res.apk "resources.arsc" member file (which contains the compiled "res/values/arrays.xml" file). If the rebuilt "resources.arsc" can be used to update ("Update" is an actual ZIP archive operation) the original framework-res.apk's member file, the updated framework-res.apk should work (and remained zip-aligned if originally zip-aligned), so long as the packed file size of the updated member file is less than or equal to the packed size of the original member file, plus up to 4 bytes depending on proximity to the next member file data if original framework-res.apk is zip-aligned as expected. If the packed modified member file(s) are larger, the original APK file structure would likely not be preserved, and a different method might have to be used. Also note that 7-Zip is not reasonable software to use for this, despite it being included with many tools on XDA to modify APK files; the software has had a history of rearranging unnecessarily zip file table entries when a change is made to an archive. Use a different tool that does not do this, such as WinRAR (I have tested version 5.61).
For normal apps, one may not copy over "resources.arsc" or resources from two different app builds and have things work correctly when the app runs; one would also need to make corresponding changes in the *.dex APK member files. framework-res.apk, not being an app the runs, has no corresponding *.dex files, and one need not worry about corrupting the relationship between the *.dex files and the resource files because none exists to corrupt.
Related
Hey guys/girls. I'm creating a theme for Andromeda 3 and one thing I cannot fifure out is how to make my theme CWM flashable to test it.
I opened the zip from a different flashable theme, replaced the framework-res.apk and twframework-res.apk with the modified ones from Andromeda and repackaged them using Winrar. I have followed the guides to resign the APK's and ZIP but no mater what I do, after a reboot I get a solid black screen and the phone vibrates.
Im not sure what I am doing wrong because I thought that was all that went into creating a CWM file.
Thanks in advance......
7 posts under this one
http://forum.xda-developers.com/showthread.php?t=1037842
the meta info is alot more specific than just swap any other files...
Thanks, I found that one about 5 mins ago but couldn't seem to find it when I searched the forum before posting. Must have missed it
Should also point out that if you're decompiling the framework apks with apktool, modifying any of the xml's or code, and recompiling, you'll need to sign the resulting apk or you'll end up with a boot loop.
modest_mandroid said:
Should also point out that if you're decompiling the framework apks with apktool, modifying any of the xml's or code, and recompiling, you'll need to sign the resulting apk or you'll end up with a boot loop.
Click to expand...
Click to collapse
Actually, I'm just opening the apk's with winrar. I make the changes to the folders/files and rezip them with Winrar with Store mode (no compression?) Then I resign them with testsign.jar.
I have read the themeing guides but they are really lacking in the small details dept.
modest_mandroid said:
Should also point out that if you're decompiling the framework apks with apktool, modifying any of the xml's or code, and recompiling, you'll need to sign the resulting apk or you'll end up with a boot loop.
Click to expand...
Click to collapse
Wrong.
Never resign system apks such as framework-res or twframework-res. His problem has nothing to do with the signature.
If you are simply copying over files inside the apk and getting this error, then you are adding more files than was originally inside the apk. I repeat, DO NOT ADD FILES THAT ARE NOT ALREADY INSIDE UNLESS YOU KNOW HOW TO RE-COMPILE THE RESOURCES.ASRC!
Also, use 7-zip to edit apks when you just want to overwrite files. Never unzip, or re-zip. Just right-click > 7-zip > Open Archive > Drag and drop files > close the window > you're done
Edit: Also, this goes in Q&A not General.
ryude said:
Wrong.
Never resign system apks such as framework-res or twframework-res. His problem has nothing to do with the signature.
If you are simply copying over files inside the apk and getting this error, then you are adding more files than was originally inside the apk. I repeat, DO NOT ADD FILES THAT ARE NOT ALREADY INSIDE UNLESS YOU KNOW HOW TO RE-COMPILE THE RESOURCES.ASRC!
Also, use 7-zip to edit apks when you just want to overwrite files. Never unzip, or re-zip. Just right-click > 7-zip > Open Archive > Drag and drop files > close the window > you're done
Edit: Also, this goes in Q&A not General.
Click to expand...
Click to collapse
Ok, thanks man.
Will I need to resign the final theme.zip before flashing it?
Also, can't I just grab the updater-script from another theme.zip and us it in my mine?
ryude said:
Wrong.
Never resign system apks such as framework-res or twframework-res. His problem has nothing to do with the signature.
Click to expand...
Click to collapse
I didn't say anything about resigning? Apktool creates an entirely new, unsigned apk, which unless I'm extremely mistaken you'll need to use if you intend to modify certain resources.
modest_mandroid said:
I didn't say anything about resigning? Apktool creates an entirely new, unsigned apk, which unless I'm extremely mistaken you'll need to use if you intend to modify certain resources.
Click to expand...
Click to collapse
He doesn't need to use apktool, because he isn't edited any code.
timbrendelaz said:
Ok, thanks man.
Will I need to resign the final theme.zip before flashing it?
Also, can't I just grab the updater-script from another theme.zip and us it in my mine?
Click to expand...
Click to collapse
No, you don't have to sign CWM zips because Clockwork doesn't check for a signature.
You could use another updater-script, but the problem with that is if it tries to perform an action on a file or folder that isn't inside your zip it will crash while flashing. You'll be left with a bricked phone and have to ODIN back to restore.
ryude said:
He doesn't need to use apktool, because he isn't edited any code.
Click to expand...
Click to collapse
But what if he is lol? Cause that's what im trying to do and having some issues. Know of a good thread on this? Editing xml that is
Sent from my SGH-T959 using XDA Premium App
TXLunchbox said:
But what if he is lol? Cause that's what im trying to do and having some issues. Know of a good thread on this? Editing xml that is
Sent from my SGH-T959 using XDA Premium App
Click to expand...
Click to collapse
If you're editing code, I recommend using apk manager since it will automatically recompile the resources.asrc for you. Just make sure to downgrade the apktool that comes with it to 1.3.1, 1.3.2 is known to cause problems with xml edits.
1. Set new project apk.
2. Decompile apk, if it's a system apk use the option for dependency apk and use twframework-res.apk as the dependency apk.
3. Edit your xml files.
4. Recompile, when asked use yes twice. It will tell you to delete files in the Keep folder.
5. Delete the resources.asrc if you edited any xml/added new files. Delete the files that you added/edited.
6. Once you're done it will automatically copy over the signature and use the compression that you set (default level 9, I recommend level 0).
Don't worry that it says "unsignedFramework-res.apk", it will work since it's a system apk because system apk signatures get copied over to the new file. Just rename it to Framework-res.apk or whatever you need it to be called.
ryude said:
He doesn't need to use apktool, because he isn't edited any code.
Click to expand...
Click to collapse
Hence the 'if' in my original statement, you know, 'if' he ever chose to in the future.
Alright, so I decompiled the apk, edited the XML files I needed to. And now it won't compile. Keeps throwing java errors. Would someone be so kind to compile this for me?
This is a System APK so it needs to be compiled and signed. If you're curious or it needs extra files pulled from somewhere, it's the SystemUI.apk in the CM7 Droid nightly build 88.
Thanks!!
Here's what I need compiled:
http://mikelierman.com/SystemUI.apk.zip
0vermind said:
Alright, so I decompiled the apk, edited the XML files I needed to. And now it won't compile. Keeps throwing java errors. Would someone be so kind to compile this for me?
This is a System APK so it needs to be compiled and signed. If you're curious or it needs extra files pulled from somewhere, it's the SystemUI.apk in the CM7 Droid nightly build 88.
Thanks!!
Here's what I need compiled:
http://mikelierman.com/SystemUI.apk.zip
Click to expand...
Click to collapse
What did you use to decompile it? APK Manager from this thread?
http://forum.xda-developers.com/showthread.php?t=695701
Oh and once you compile it, you don't have to sign it because is a system app and not a regular app.
0vermind said:
Alright, so I decompiled the apk, edited the XML files I needed to. And now it won't compile. Keeps throwing java errors. Would someone be so kind to compile this for me?
This is a System APK so it needs to be compiled and signed. If you're curious or it needs extra files pulled from somewhere, it's the SystemUI.apk in the CM7 Droid nightly build 88.
Click to expand...
Click to collapse
What errors are you getting from apktool? It's going to be hard for someone else to compile an apk that has not been decoded by them and not knowing what files have been changed. Letting us know at least what .png or .xml files were modified would be a start but will work best if we could just figure out why you aren't able to build with your modifications.
The first thing I noticed from the zip you attached is that it's missing the apktool.yml file that should get created a package is decoded. Second, make sure to pull /system/framework/framework-res.apk so resources can be decoded/built properly. If you are using APK Manager, use option 10 to decode with framework-res.apk. If you are just using apktool run the command "apktool if framework-res.apk" before decoding.
mazdarider23 said:
Oh and once you compile it, you don't have to sign it because is a system app and not a regular app.
Click to expand...
Click to collapse
SystemUI.apk actually does get signed using the platform key. The easiest way to do so in my opinion is to use ZipSigner 2 on your phone. Also, once you've placed the modified SystemUI.apk into /system/app make sure it's permissions are rw-r--r--(chmod 644 /system/app/SystemUI.apk) and it's owner:group is root:root(chown 0:0 /system/app/SystemUI.apk). Next reboot to recovery, wipe dalvik-cache and cache, then reboot.
MongooseHelix said:
What errors are you getting from apktool? It's going to be hard for someone else to compile an apk that has not been decoded by them and not knowing what files have been changed. Letting us know at least what .png or .xml files were modified would be a start but will work best if we could just figure out why you aren't able to build with your modifications.
The first thing I noticed from the zip you attached is that it's missing the apktool.yml file that should get created a package is decoded. Second, make sure to pull /system/framework/framework-res.apk so resources can be decoded/built properly. If you are using APK Manager, use option 10 to decode with framework-res.apk. If you are just using apktool run the command "apktool if framework-res.apk" before decoding.
SystemUI.apk actually does get signed using the platform key. The easiest way to do so in my opinion is to use ZipSigner 2 on your phone. Also, once you've placed the modified SystemUI.apk into /system/app make sure it's permissions are rw-r--r--(chmod 644 /system/app/SystemUI.apk) and it's owner:group is root:root(chown 0:0 /system/app/SystemUI.apk). Next reboot to recovery, wipe dalvik-cache and cache, then reboot.
Click to expand...
Click to collapse
Well I'm glad you told me because little old me has been modifying system apps since the days of the nexus one and I've yet to sign one....I think is all depends on who's doing the modification...hahahaha....Good luck 0vermind on finding someone to compiling your systemui.apk!
mazdarider23 said:
Well I'm glad you told me because little old me has been modifying system apps since the days of the nexus one and I've yet to sign one....I think is all depends on who's doing the modification...hahahaha....Good luck 0vermind on finding someone to compiling your systemui.apk!
Click to expand...
Click to collapse
I'm not quite sure what to make of that comment...I certainly wasn't trying to step on your toes so I apologize if it came across that way. Just wanted to help avoid and rule out any issues that might come up. With APK Manager or by using 7zip, you can move the manifest and/or META-INF folder containing the signature from the original but to imply that system apps are not signed is incorrect.
I also think it is important that those messing with system apps understand that there are different keys used to sign apps. For anybody reading this that wants to figure out how certain packages are signed, here's a bit of an explanation. If we extract SystemUI.apk, we see a directory called META-INF. This holds the key/signature info. The key's serial number can be determined with the following command:
Code:
keytool -printcert -v -file SystemUI/META-INF/CERT.RSA | grep SerialNumber
You can check other apks/jars and noticing which have matching serial numbers, meaning they are signed with the same key...
platform key - SystemUI.apk, Settings.apk, Phone.apk, etc
shared key - Contacts.apk, UserDictionaryProvider.apk, etc
test key - Calendar.apk, DeskClock.apk, etc
google proprietary key - Vending.apk, Talk.apk, etc (including some market user apps like Maps, VoiceSearch, Docs)
MongooseHelix said:
I'm not quite sure what to make of that comment...I certainly wasn't trying to step on your toes so I apologize if it came across that way. Just wanted to help avoid and rule out any issues that might come up. With APK Manager or by using 7zip, you can move the manifest and/or META-INF folder containing the signature from the original but to imply that system apps are not signed is incorrect.
I also think it is important that those messing with system apps understand that there are different keys used to sign apps. For anybody reading this that wants to figure out how certain packages are signed, here's a bit of an explanation. If we extract SystemUI.apk, we see a directory called META-INF. This holds the key/signature info. The key's serial number can be determined with the following command:
Code:
keytool -printcert -v -file SystemUI/META-INF/CERT.RSA | grep SerialNumber
You can check other apks/jars and noticing which have matching serial numbers, meaning they are signed with the same key...
platform key - SystemUI.apk, Settings.apk, Phone.apk, etc
shared key - Contacts.apk, UserDictionaryProvider.apk, etc
test key - Calendar.apk, DeskClock.apk, etc
google proprietary key - Vending.apk, Talk.apk, etc (including some market user apps like Maps, VoiceSearch, Docs)
Click to expand...
Click to collapse
Thanks, I didn't know this! I'm glad there's people like you and mazdarider23 on this forum that know **** like this!!!
Hello. I would like to know if anyone has an actual beginner's guide to CIQ removal. For a minute, there was a guide that didn't quite have all the bugs worked out of it, but it was removed. I've been trying to follow Krylon's thread on rootzwiki, but it seems to stop short of telling people how to actually recompile everything and push it back to the phone. It would be helpful and informative to be walked through this process once the CIQ files have been deleted from the decompressed classes.dex files and .xml manifest.
Thanks
Note: So far, I have figured out that autosmali can be used to smali the files back into a classes.dex file, which can be reincorporated into the associated .jar files using 7zip. Seems simple enough. However, the process of getting framework-res updated seems to be more complicated, and requires answering some questions about. Specifically: 1. Option 11 asks (a) Is this a system apk? (b) Aside from the signature, would you like to copy over any additional files that you didn't modify from the original apk in order to ensure least # of errors? I have answered "yes" to 1.(a) and "yes" to 1.(b), which told me to delete the .xml and the resources.arcs file from a temp directory before completing the compile. This whole process has left me with three modified files (framework.jar, android.policy.jar, and framework-res.apk (unsigned)). Now what do I do with them?
Note 2: Looks like I can sign the framework-res.apk file using option 12.
Once you are done modifying the files you need to either put them in an update.zip and flash or push them with adb to their respective folders.
As for someone giving a step by step I doubt that will happen. It seems like the ones that do know how to do alot of the modifications to roms, are pretty vague when they post how to's. Most of the time it seems like they just don't want to share the information. Why I don't know, but that is just my opinion. I am sure I will probably get flamed for saying this but again this is just my opinion.
You can search the forums and find most of the information here and there. Then you need to put it all together and hope it works.
My thought's would be to have a seperate area in the forum to post just Tips, Techniques and How To's. Then alot of the people that want to learn how to theme and build roms would have an better source to find their answers than having to search all the forums. Again just my .02 cents worth...
Hope no one is offended by this as that is not my intention.... XDA is a great source for information...
quick steps..
Decompile Framework.jar, delete the entire carrieriq dir and all it's contents, recompile.
delete /system/xbin/iqbridger
DONE
Makes the rest dead code.
tablador said:
Hello. I would like to know if anyone has an actual beginner's guide to CIQ removal. For a minute, there was a guide that didn't quite have all the bugs worked out of it, but it was removed. I've been trying to follow Krylon's thread on rootzwiki, but it seems to stop short of telling people how to actually recompile everything and push it back to the phone. It would be helpful and informative to be walked through this process once the CIQ files have been deleted from the decompressed classes.dex files and .xml manifest.
Thanks
Note: So far, I have figured out that autosmali can be used to smali the files back into a classes.dex file, which can be reincorporated into the associated .jar files using 7zip. Seems simple enough. However, the process of getting framework-res updated seems to be more complicated, and requires answering some questions about. Specifically: 1. Option 11 asks (a) Is this a system apk? (b) Aside from the signature, would you like to copy over any additional files that you didn't modify from the original apk in order to ensure least # of errors? I have answered "yes" to 1.(a) and "yes" to 1.(b), which told me to delete the .xml and the resources.arcs file from a temp directory before completing the compile. This whole process has left me with three modified files (framework.jar, android.policy.jar, and framework-res.apk (unsigned)). Now what do I do with them?
Note 2: Looks like I can sign the framework-res.apk file using option 12.
Click to expand...
Click to collapse
Don't use option 12.
NEVER SIGN A SYSTEM APK
krylon360 said:
Don't use option 12.
NEVER SIGN A SYSTEM APK
Click to expand...
Click to collapse
Thanks krylon for the quick fix.
If, for completeness, I wanted to put all of these modified files on my phone (unsigned), how would I do it? Last time I tried, I used a root file explorer and my phone started bootlooping immediately after placing framework-res.apk on the phone. Adb was not available, so I had to reflash in order to put the file back the way it was. I was thinking maybe to adp push the file instead of copying it with the explorer.
adb push then reboot.
but, it's best to do it as a fresh install.
Thanks, I will give that a try.
Followed these directions 3x, but when I boot up my phone with these changes, the Android System process stops responding every time i boot my phone. I can bypass the error message fine, though.
edit: Well, after reflashing it 2 more times with the exact same rom, it doesn't happen anymore. MEH, who knows?
One of Raver's ROMs did that too. I think it is a dependency to something you removed. It was fine on the ROM. One FC when you boot ROM and that was it.
Hello,
I a quite new to Android development/hacking and need some clarification regarding signing system apps.
I did not find any answer yet that fully helped me solve my problem...yes, I did use search on the forum and even Google :laugh:
Scenario:
Let's assume I wanted to modify some system apks (in /priv-app or /app doesn't matter).
All those apks I want to modify do rely on the same framework.apk.
As far as I know, if I modify a system apk all other system apks that rely on the same framework.apk have to be resigned using the same certificate.
1) Is this correct (any pitfalls there)?
2) Do I have to resign the used framework.apk with the same certificate also?
3) Do I have to take other files/things into consideration that would have to be changed / resigned / etc.?
Thanks in advance! :good:
Regards
Markus
deomaki said:
Hello,
I a quite new to Android development/hacking and need some clarification regarding signing system apps.
I did not find any answer yet that fully helped me solve my problem...yes, I did use search on the forum and even Google :laugh:
Scenario:
Let's assume I wanted to modify some system apks (in /priv-app or /app doesn't matter).
All those apks I want to modify do rely on the same framework.apk.
As far as I know, if I modify a system apk all other system apks that rely on the same framework.apk have to be resigned using the same certificate.
1) Is this correct (any pitfalls there)?
2) Do I have to resign the used framework.apk with the same certificate also?
3) Do I have to take other files/things into consideration that would have to be changed / resigned / etc.?
Thanks in advance! :good:
Regards
Markus
Click to expand...
Click to collapse
All system apps have to be signed the same way, yes. You can sometimes mod your services.jar to turn off signature verification but that can leave you a bit more open to malware.
When you mod a system app, you just have to make sure you use the original signature in the new version. The only exception to this is if you change anything in the manifest. Then you will need a new signature, which means either signing everything else with that signature or doing the services.jar I mentioned earlier.
Hello Ticklefish,
first of all: Thanks a lot!
To summarize your answer:
1) Modding services.jar is out of the question! Would never have done this anyway...(risky from a malware point of view)
2) In case I modify a system apk WITHOUT altering the manifest.xml I can reuse the old apk signature for my new apk (the whole META-INF folder has to be copied over to the new apk?)
Nothing else has to be adjusted?
I suppose I still can do a zipalign afterwards in that case?
3) In case of modifying the manifest.xml I would have to resign ALL system apks.
All of them or only those that rely on the same framework as the modded apk?
Do I have to resign the framework apk as well?
I am asking, because I will have to mod several apks relying on different frameworks: At least one where I have to alter manifest.xml...
Thanks in advance
Markus
deomaki said:
Hello Ticklefish,
first of all: Thanks a lot!
To summarize your answer:
1) Modding services.jar is out of the question! Would never have done this anyway...(risky from a malware point of view)
2) In case I modify a system apk WITHOUT altering the manifest.xml I can reuse the old apk signature for my new apk (the whole META-INF folder has to be copied over to the new apk?)
Nothing else has to be adjusted?
I suppose I still can do a zipalign afterwards in that case?
3) In case of modifying the manifest.xml I would have to resign ALL system apks.
All of them or only those that rely on the same framework as the modded apk?
Do I have to resign the framework apk as well?
I am asking, because I will have to mod several apks relying on different frameworks: At least one where I have to alter manifest.xml...
Thanks in advance
Markus
Click to expand...
Click to collapse
If you're modifying an APK without changing the manifest, the best method is to use 7zip or similar to open the new APK and drag the modded files over to the original APK. That way you're still using the same META-INF at the same compression ratio.
Or use Tickle My Android (https://forum.xda-developers.com/showthread.php?t=1633333) to do it for you....cough...cough...
You can zipalign afterwards, just remember that any further changes will affect that zipaligning so you'll have to do it again.
As far as resigning the APK goes, all I know is that you have to change every file that uses the same key/signature as the app you resigned so that they all match.
I have to confess that I've never actually done this. I rarely change the manifest myself and, when I do, I disable signature verification. Yes, it makes you more prone to malware but as long as you're careful about what you install you should be okay.
deomaki said:
Hello,
I a quite new to Android development/hacking and need some clarification regarding signing system apps.
I did not find any answer yet that fully helped me solve my problem...yes, I did use search on the forum and even Google :laugh:
Scenario:
Let's assume I wanted to modify some system apks (in /priv-app or /app doesn't matter).
All those apks I want to modify do rely on the same framework.apk.
As far as I know, if I modify a system apk all other system apks that rely on the same framework.apk have to be resigned using the same certificate.
1) Is this correct (any pitfalls there)?
2) Do I have to resign the used framework.apk with the same certificate also?
3) Do I have to take other files/things into consideration that would have to be changed / resigned / etc.?
Thanks in advance! :good:
Regards
Markus
Click to expand...
Click to collapse
I usually use Mixplorer, (if you use your phone to de/re-compile). Click on compiled apk, select 'explore' and a new tab opens with the contents of the apk. Delete the manifest that was created in recompile, then go to folder with decompiled apk, /original, and long-press to select android manifest xml, and META-INF folder. Choose copy, and paste them into new apk.
Hi all,
I'm trying to fiddle with a Google apk file that I'm reskinning. Essentially there are multiple versions of the app in the wild already, but one has a dark grey background and I'm trying trying to make it all black.
I figure I need to change the xml file contained within the app. I guess I can just root and edit the xml file that way but I want to stay un-rooted if possible. That means editing the APK.
I downloaded Android Multitool and am trying to unpack the APK, make the necessary changes, and repack it. I'll probably run into signature issues down the road but currently I'm stil struggling with repacking. Specifically, I think I need a framework-res.apk, which I don't know how to find.
I'm assuming I need a stock Android framework-res.apk given the nature of the app, but I don't know where to find one....