Guys, is there any way to replace an APK or something to get a UK dialer on the JF ADP1 build?
I know it doesnt make any functional difference, but I like my numbers to show correctly
Any help would be very welcome.
yh i would like to know this too, its pretty annoying
cheers
Nobody knows how to do this? Surely someone has an idea?
I tried copy/replacing the phone.apk and that didnt do anything (apart from dropping my network link and bringing it back up).
Any clues?
What about the contacts app? (maybe the dialer activity isn't in phone.apk, but in there?)
Also, to be completly sure, reboot after copying (to make sure the old one is out of memory)
The phone number format function doesn't belong to any application. It is in the base library, /system/framework/base.jar.
Now in the source tree, there are only supports to NANP(US, CA and etc. using it) and Japan format. Maybe the UK format is a patch from carrier.
You can read related code from: http://android.git.kernel.org/?p=pl...42fcfe2f57908f1725fd53f2fccbc6d4df96b;hb=HEAD
Oh, so it's hidden in the framework?
Hmm... I should be able to add an extra function there for UK/DK/Unformatted... theres no such thing as /system/framwork/base.jar, but i believe the base framework compiles to framework.jar and framework-res.apk.
Anyway, I'll take a look, and see how rusty my java has become
EDIT:
Just tried to compile the framework from the master-branch, and that didn't quite work as planned... I backed up the old framework.jar/odex and framework-res.apk, and tried to push the clean(non-modified, freshly-compiled) and RC8-mod frameworks to system... suddenly, there was missing 4096KB for the odex file... did the logs fill up with errors while missing it? And it didn't quite wan't to run without the odex (DexOpt:mismatch dep name, and android.policy.jar odex has stale dependencies)
If it's the logs filling up the /system partition, it could probably be fixed by pushing the files to data/local first, then copy them to the system partition in the recovery console... and the dalvik cache problem could probably be fixed by clearing the cache...
Joushou said:
theres no such thing as /system/framwork/base.jar, but i believe the base framework compiles to framework.jar and framework-res.apk.
Click to expand...
Click to collapse
Sure! I was wrong. It is framework.jar
Joushou said:
Just tried to compile the framework from the master-branch, and that didn't quite work as planned... I backed up the old framework.jar/odex and framework-res.apk, and tried to push the clean(non-modified, freshly-compiled) and RC8-mod frameworks to system... suddenly, there was missing 4096KB for the odex file... did the logs fill up with errors while missing it? And it didn't quite wan't to run without the odex (DexOpt:mismatch dep name, and android.policy.jar odex has stale dependencies)
If it's the logs filling up the /system partition, it could probably be fixed by pushing the files to data/local first, then copy them to the system partition in the recovery console... and the dalvik cache problem could probably be fixed by clearing the cache...
Click to expand...
Click to collapse
I did try many times and ways (include recovery console) to replace the official release of framework.jar with the one compiled by myself. Always got the "dependencies" problems. I guess, the reason is digital signature mismatch. If you find out how to do it, I'd like to know how!
I think you should be looking at changing the base local to UK instead of US, that way PhoneNumberUtils.java will return as an unkown area and not format the number.
Code:
/** The current locale is unknown, look for a country code or don't format */
public static final int FORMAT_UNKNOWN = 0;
/** NANP formatting */
public static final int FORMAT_NANP = 1;
/** Japanese formatting */
public static final int FORMAT_JAPAN = 2;
So you would need to get
Code:
getFormatTypeForLocale(Locale.getDefault())
to return a value not in the local array.
This seems quite complex... all to get a build to show my network name AND have correct dialer strings B-)
I will investigate the difference between RC8 and ADP regarding the network name (vodafone UK) etc and see what shows up there. That way I can create an altered RC8 to habdle all networks nicely.
Thanks all.
Rich
Sure, but the problem seems to be replacing the jar.
If i can't use from another build, i would have to make a complete system to replace that single framework file, and thus losing most apps (GApps, market, stuff like that)...
So, unless someone knows how to compile a jar that will fit the builds, i can't patch it
Related
To create themes, or to edit themes to your liking, you will need a working knowledge of android, adb, how to resign apk's, knowledge of your own O/S.
Before you start be aware that you will probably end up wiping your phone once, if not more. So lets go over the things that you will need.
You will need JF's RC30, RC8, or ADP1 V1.3, depending on what version you intend to create for.
Here is the link to these: http://forum.xda-developers.com/showthread.php?t=466174
You will also want to get the dev bootloader installed on your phone and to HIGHLY suggest everyone trying your theme to install it as well.
Link to dev bootloader: http://forum.xda-developers.com/showthread.php?t=455860
You will also need to resign all the apks located in /system/app and framework-res.apk located in /system/framework. When you push all of these to your phone, you will need to do a wipe.
JesusFreke was kind enough to build a custom signing tool for me that would allow me to right click on an apk and resign it from there. I am posting it here for others to use as well. Note that this is a courtesy of JF, so thank him for it. I cannot stress how much time this has saved me and will save you.
Here is the link: Http://www.FightForthePits.com/testsign(2).zip
Before using this you need to know how to set this up:
I will assume that you have the sdk downloaded and extracted somewhere(if not, do that now), extract both files to the tools directory of your sdk.
Now you will need to add the tools dir of your sdk to the environment variable CLASSPATH.
To do this, right click on My Computer click properties, then choose the tab that says advanced. Click the button that says environmental variables. Go to system variables find the one that says CLASSPATH, double click it, go to the end of variable value. There should be a semicolon ; at the end. type in the path to the testsign.jar located in the tools directory of your SDK, for example the path to my testsign.jar was c:\sdk\android-sdk-windows-1.0_r1\tools\testsign.jar If CLASSPATH is not in your system variables then create it.
If you find the right click menu not working for some reason you can type the following in cmd to sign your files: java testsign whateverfiletosign
Now right click the reg file that you extracted and choose to install it, or merge.
Now, right click an apk, do you see an option that says ResignApk? If not hit the windows key and R at the same time. Type in regedit. go to HKEY_CLASSES_ROOT and expand it. Now find .apk and click it. Double click on (Default) and erase apk_auto_file. Hit ok and close the Reg editor. Now right click an apk and the option ResignApk should be there.
Now through doing this you have done two things, first off you have made the resigning process extremely easy, secondly you will not have to cd to the tools dir of the sdk to use adb or any other tool in the sdk.
You will also need a version of linux installed or running vmware with linux, so that you can create an update file which will install the theme onto the users phone.
You need to make sure that you do this correctly, because if you don't then you will have the potential to create problems for people trying to install your theme. You also need to be specific in addressing what version your theme is for, RC8, RC30, or ADP1. Make sure every file gets signed. Make sure you test the update.zip before you release it.
Every .apk contains the images relating to itself. However, every apk has the ability to use the images in framework-res.apk. The images for every apk is located inside of res and more specifically in folders that are named Drawable, drawable-land, drawable-port, etc. Some things you cannot edit unless you rebuild the entire apk from source, which we will not go into here.(another tutorial, another time) Just know that at this time you SHOULD NOT edit, or even open images with the extension .9.png. If you do you will have problems...Trust me. These are special images called ninepatch images and android resizes these images to fit wherever android, or any other apk, needs it to. if you do open them or edit them they will no longer render correctly when resized. I believe that in order to edit these you must do so and then put them into the source and rebuild the entire apk.
Before getting started you must also realize that you cannot simply resign one or two apk's and stick them in your phone and expect them to work. You must resign every apk inside of /system/app and framework-res.apk and put them on your phone at the same time.
To simplify this process for you though, I have provided an update which will do all of this for you. Note that these updates will not completely wipe your phone, your apps will be retained, however, they will require you to re-enter your Google info, and you will lose you call history.
Links down
Just put the correct update.zip, depending on what version you are running, onto your sd card, boot into recovery and hit alt + s.
Now you can push your own apk's one at a time without re-wiping your phone.
Now, your ready to start changing things up.
You will now need to open the apk, which you can do by adding .zip after .apk, effectively changing it to a zip. Note that if you are using windows you will need to unhide known file extension types.
See here to unhide known file extension types for Xp: http://www.mediacollege.com/microsoft/windows/extension-change.html
See here to unhide file extension types for Vista: http://maximumpcguides.com/windows-vista/how-to-change-a-file-extension/
After changing the apk to a zip open it go to res and copy the folders that have drawable in their name. Go to your desktop, or wherever, create a new folder called Images, or whatever. Open the folder, paste the drawable folders in there. Now you can see what the files look like without opening them. Btw, you may also want to add -frame, or -launcher, to the end of the folders you cope over to keep them separated from others.
Finally, you've edited the images put them all in the apk renamed it back to an apk and resigned it. Now it's time to push it to your phone and see the changes you've made.
Important! : Whenever pushing files to the phone NEVER do it while the phone is running. Do this in recovery mode! If you do this while the phone is running normally you will begin to lose space in /system.
So, boot into recovery plug your phone in and open a cmd prompt. From the cmd prompt type adb shell mount /system then type the following: adb push c:\whereveryourfileis\whateveryourpushing.apk /system/app (system/framework if your pushing framework-res.apk)
Now reboot your phone. If it doesn't boot, try doing a wipe, if that doesn't work reinstall an update and try again. There are alot of things people can do wrong, I can't explain them all here. If you get real stuck, you can ask for help here or contact me on Gtalk [email protected].
So now your theme is done and your ready to make an update.zip for others to install your theme.
This must be done in LINUX! Not WINDOWS! Yes it may work for you if you do it in windows but other people's phones will enter an indefinite loop! Just do it from Linux! If you absolutely cannot make your own update.zip, contact me and we'll see if I can make one up for ya.
I have created a template for you to make your own update.zip. Just download, open in Linux, and add the system apps to app, and framework to framework. Zip it up, SIGN IT, TEST IT YOURSELF, and then distribute it!
Empty update.zip template: Http://www.FightForthePits.com/Androidstuff/update_empty.zip
If anyone has any questions please try asking for help in this thread before emailing me for help Usually I will respond to questions in this forum.
I hope this Tutorial has been helpful. I will add on to it as needed.
Stericson
Links of interest:
Downloading SDK: http://code.google.com/android/intro/installing.html
Using ADB: http://code.google.com/android/reference/adb.html
Working with ninepatch should be straightforward if you use the draw9patch tool included in the SDK. Documentation on usage here:
http://code.google.com/android/reference/draw9patch.html
JF could also save theme users a wipe by resigning /system/app/* and /system/framework/framework-res.apk in his builds with the test keys. Nice tutorial, btw.
However it doesn't. I have used that to no avail. I believe you need to edit the images, put them in the source then rebuild the apks from the source.
As for JF's update, it does not currently wipe your phone after install. So, for him to do this he would have to have his update do a wipe. So technically, they would still have to do this initial wipe.
Stericson
Stericson said:
However it doesn't. I have used that to no avail. I believe you need to edit the images, put them in the source then rebuild the apks from the source.
Click to expand...
Click to collapse
Good point. I thought you could simply drop a similarly dimensioned PNG in but apparently there is some metadata that only the android tool can create.
As for JF's update, it does not currently wipe your phone after install. So, for him to do this he would have to have his update do a wipe. So technically, they would still have to do this initial wipe.
Click to expand...
Click to collapse
True, but a user who is upgrading to a JF update after having put in customized (and test-key signed) system apps will have to wipe again anyway =) Anyone using custom themes will have to wipe every time a JF update (or any update) comes out. However if JF resigns, custom theme users would not have to wipe and stock theme users only have to wipe once. (Nevermind the fact I think everyone should wipe when updating...)
thx stericson this will help big time how long before I can get resigned rc30 last night when you said all the apk. need to be resigned I was like this is going to be a long night but I see jf hooked you up save some big time with his resigning tool
jashsu said:
Good point. I thought you could simply drop a similarly dimensioned PNG in but apparently there is some metadata that only the android tool can create.
True, but a user who is upgrading to a JF update after having put in customized (and test-key signed) system apps will have to wipe again anyway =) Anyone using custom themes will have to wipe every time a JF update (or any update) comes out. However if JF resigns, custom theme users would not have to wipe and stock theme users only have to wipe once. (Nevermind the fact I think everyone should wipe when updating...)
Click to expand...
Click to collapse
Ah, good point
The resigned apps will be released maybye sometime tonight...I had them done but ran into a script problem on adp1 and I have yet to try the rc30 and rc8 ones yet. so I won't release those until I've tested them. If you want to be a Guinea pig however, just let me know
Stericson
Stericson said:
Ah, good point
The resigned apps will be released maybye sometime tonight...I had them done but ran into a script problem on adp1 and I have yet to try the rc30 and rc8 ones yet. so I won't release those until I've tested them. If you want to be a Guinea pig however, just let me know
Stericson
Click to expand...
Click to collapse
The resigned apps have been released, each update file will resign all of apps in /system/app and framework-res.apk. However, these updates make no changes to them whatsoever...Meaning your phone will look just like a brand new phone without any modifications.
rc30 works thx Stericson made it easy for use
Issues with using the update.zip above
Hi all,
I just wanted to point out that after I applied the update.zip above and rebooted applications kept force closing randomly and constantly even through the initial setup (where you have to click the green android to start).
Prior to this, I had JF's RC30 1.3, and the engineering bootloader V2 no sigcheck.
First I did just a alt+s then a alt-w and alt+s. And still nothing.
I'm new to all this so I'm not even sure where to begin troubleshooting. Should I be using the HardSPL?
Thanks in advance and I appologize if this isn't the right place for this post.
Update:
After reflashing with JF's 1.3 RC30 and the problem persisted I noticed that there was a new release 1.31 and this has fixed the problem. I hope this helps anyone else who runs into the same problem.
I still don't know what went wrong though, can anyone shed some light on this? thanks.
Truly there's no telling, sounds like J'f's update fixed it. Can I ask what version you tested?
I would also like to announce that now, thanks to JF, again, you do not have to wipe your phone completely to apply the resigned app updates. However, you will have to re-enter your google info and your call history and other minor things will be gone, but all of your apps will be retained.
Stericson
Stericson said:
Truly there's no telling, sounds like J'f's update fixed it. Can I ask what version you tested?
I would also like to announce that now, thanks to JF, again, you do not have to wipe your phone completely to apply the resigned app updates. However, you will have to re-enter your google info and your call history and other minor things will be gone, but all of your apps will be retained.
Stericson
Click to expand...
Click to collapse
Hey, I tested it with this one:
Rc30 resigned: http://www.fightforthepits.com/Andro...pdate_Rc30.zip
Update went fine, until I booted back up then the applications kept force quitting, without me even doing anything.
Thanks,
Limitlis
yes there is a temp problem with those right this moment I am on the problem as we speak, expect a fix tonight...
Stericson
Can we get the fix cuz it bricking fone I had to flash rc29 nbh
Edit: I forgot please.... feel kinda rude when ur helping me out lol but it bricking some phones and for our less experince members we don't global meltdown lol
These files have been fixed and uploaded.
Stericson
I found the cyclon boot effect images in in framework-res/assets/images,
is there any way to replace the android boot image with those images?
Is there anyway to make the theme with a custom boot screen? Also is there a way to change the second boot screen(The one that says Android and has the little robot)
i tried using the testkeys from JF to resign my apks, but the update still says there is not signature =[
hello, I used the tutorial and everything worked great. I'm trying to change the background to the notification section but I can't find that file. Could you tell me where it is? Thank you.
hey stericson, how do u create a theme for rc33?
Hey guys, so this script de-odexe's a rom's apks and jar's.
Many thanks to ofcourse JesusFreke who created this method and the way to do it. Also to coolbho for his apkopt script from which i learnt certain techniques of batch programming. This is crzyruski script updated with jesus freke's latest smali/baksmali update ver 1.2.3
It incorporates detecting the bootclasspath of the odex instead of the user specifying it. For non standard odex however a specific bootclass path must be defined. For example:
According to Jr33 for rosie deodexing u have to add class paths com.htc.framework.jar. Thank him for the new Sense bootclasspaths
For those who dont know, this essentially uses jf's method of baksmali'ing the odex file into smali files, and then recreating the classes.dex file and packaging it into the apk hence disregarding the need for the odex.
*New Menu added
*Ability to specify custom bootclasspath (eg for sense ui)
*Added a java check at the beginning
*Added 1.2.3 smali/baksmali with froyo support(thank jf ofcourse )
*Modified it so if an error is encountered during deodexing, it leaves that file behind so once done you know what files encountered errors
*Added Ignore Mode
*Removed zipalign
*If apk doesnt have corresponding odex, it moves it to deodexed_APK instead of user manually moving it
*Added compression level option
*You can monitor the status of ignore mode / compression level right above the main menu
DISCLAIMER:
Its a batch file so it'll only work on windows.
Convince farmatito to bring this to linux
Thanks
So I checked this out and all ...
It's only apk's, right?
I only glanced but I didn't see anything in there for framework, etc.
If I'm right, then perhaps .. you should just say it de-odex's a ROM's apk's instead of the entire ROM.
~enom~
enomther said:
So I checked this out and all ...
It's only apk's, right?
I only glanced but I didn't see anything in there for framework, etc.
If I'm right, then perhaps .. you should just say it de-odex's a ROM's apk's instead of the entire ROM.
~enom~
Click to expand...
Click to collapse
Oh, yea so it takes the apk and odex and creates the classes.dex and repackages into the apk so u only need the apk. Ok, ill change the post a bit also yes, it doesnt do frameworks cuz i dont think they have odex's and the jar's do but i dunno of a method to do tht
Daneshm90 said:
Oh, yea so it takes the apk and odex and creates the classes.dex and repackages into the apk so u only need the apk. Ok, ill change the post a bit also yes, it doesnt do frameworks cuz i dont think they have odex's and the jar's do but i dunno of a method to do tht
Click to expand...
Click to collapse
Yea ... the jar's have dex's too and can be odex-d and can also be un-odex-d. I personally have never been able to successfully de-odex a fully odex'd framework (but I haven't tried hard enough either ). The main difference is once they are de-odex'd ... you insert the classes.dex into the jar and no re-signing required (as they aren't signed).
Either way, nice script mate. Good Job!
~enom~
enomther said:
Yea ... the jar's have dex's too and can be odex-d and can also be un-odex-d. I personally have never been able to successfully de-odex a fully odex'd framework (but I haven't tried hard enough either ). The main difference is once they are de-odex'd ... you insert the classes.dex into the jar and no re-signing required (as they aren't signed).
Either way, nice script mate. Good Job!
~enom~
Click to expand...
Click to collapse
Ah sweet, something i shall incorporate in the script later on. thanx
so will this script allow you to take an app from say a cliq dump and allow it to run on any android device?
Will this allow you to grab the MyFaves from a TMO rom and de-odex it and install?
Joe333x said:
so will this script allow you to take an app from say a cliq dump and allow it to run on any android device?
Click to expand...
Click to collapse
Emm...no im 99.99% sure it doesnt help tht way. I know that odex's cause customization problems in roms....there are other factors im sure
mrandroid said:
Will this allow you to grab the MyFaves from a TMO rom and de-odex it and install?
Click to expand...
Click to collapse
MyFaves == No Go ... it requires some other form of trickery ... I'm not sure what exactly ... as I did de-odex it and it would not work properly on test-key ROM's like CM, etc.
... So it requires more than a simple de-odex.
~enom~
does your phone need to be connected? I noticed some ADB commands in the script
Daneshm90 said:
Hey guys, so this script de-odexe's a rom's apks.
Many thanks to ofcourse JesusFreke who created this method and the way to do it. Also to coolbho for his apkopt script from which i learnt certain techniques of batch programming
For those who dont know, this essentially uses jf's method of baksmali'ing the odex file into smali files, and then recreating the classes.dex file and packaging it into the apk hence disregarding the need for the odex.
Oh also make sure to place only apk's that have their corresponding odex's. Dont place only apk's !!!!!
Instructions:[WINDOWS ONLY & Phone Must stay connected with adb WORKING]
1. Download http://www.mediafire.com/?mwownkhzm4m
2. Extract to a folder
3. Place all your rom's apk's which have odex's attached to them into that folder
4. Run deoall
5. Copy all the apk's from the deodexed folder into ur corresponding rom app folder
Thanks
Upcoming:
Seperate Framework & apps folder
De-odex framework apk's and jar's (thanx for the tip enomther )
Click to expand...
Click to collapse
So the apk after that has the DEX built in or is dexopt still needed?
wesgarner said:
So the apk after that has the DEX built in or is dexopt still needed?
Click to expand...
Click to collapse
>.<.......................
kingklick said:
>.<.......................
Click to expand...
Click to collapse
Hey I am just double checking
If you're having problems de-odexing the framework is because there's a particular order to it.
If you look at your bootclasspath you'll see the framework files necessary to boot the android system, the rest (whatever's not in there) can be dexopted in any order.
If you're trying to de-odex the framework, you're going to have to backtrace yourself.
Personally, I do:
for i in /system/app/*.apk
unodex
for j in /system/framework/nonCoreJar1.jar /system/framework/nonCoreJar2.jar /system/framework/...nonCoreJarN.jar
unodex
for k in /system/framework/bootClassPathJarN.jar /system/framework/bootClassPathJarN-1.jar /system/framework/...bootClassPathJarN-y.jar
unodex
it requires a couple of reboots along the way to deal with any created dalvik-cache so that it doesn't interfere with the next needed classes.dex
the only turn-off was that it requires a running system to do it (it's not that big of a problem, but porting and then flashing starts getting old after a while).
Has that changed?
Does OP mean you can take the apks, toss them into a folder, and then do it from the computer without the phone?
---edit---
shoot me for not reading.
Daneshm90 said:
Instructions:[WINDOWS ONLY & Phone Must stay connected with adb WORKING]
Click to expand...
Click to collapse
jubeh said:
If you're having problems de-odexing the framework is because there's a particular order to it.
If you look at your bootclasspath you'll see the framework files necessary to boot the android system, the rest (whatever's not in there) can be dexopted in any order.
If you're trying to de-odex the framework, you're going to have to backtrace yourself.
Personally, I do:
for i in /system/app/*.apk
unodex
for j in /system/framework/nonCoreJar1.jar /system/framework/nonCoreJar2.jar /system/framework/...nonCoreJarN.jar
unodex
for k in /system/framework/bootClassPathJarN.jar /system/framework/bootClassPathJarN-1.jar /system/framework/...bootClassPathJarN-y.jar
unodex
it requires a couple of reboots along the way to deal with any created dalvik-cache so that it doesn't interfere with the next needed classes.dex
the only turn-off was that it requires a running system to do it (it's not that big of a problem, but porting and then flashing starts getting old after a while).
Has that changed?
Does OP mean you can take the apks, toss them into a folder, and then do it from the computer without the phone?
Click to expand...
Click to collapse
Yea I would figure as much ... simply b/c one must follow the BOOTCLASSPATH order when odex'ing ...
So Jubeh .. you're saying you've personally de-odex'd an fully odex'd framework b4?
Just looking for confirmation from someone who has personally ... since I'm too lazy to go through that hectik crappy process
~enom~
enomther said:
Yea I would figure as much ... simply b/c one must follow the BOOTCLASSPATH order when odex'ing ...
So Jubeh .. you're saying you've personally de-odex'd an fully odex'd framework b4?
Just looking for confirmation from someone who has personally ... since I'm too lazy to go through that hectik crappy process
~enom~
Click to expand...
Click to collapse
I did it with the tattoo build, but upon boot I would get all sorts of fc's, but I think that was due more to a bad, hasty port than the deodexing. It was also a long time ago when the tool first came out, dont know if there's been newer revisions, so I'll try it again on that funky tattoo rom.
K guys one problem i found after doing multiple apk's is that i need to give the listening dex command a bit delay so its ready for baksmali. I was doing it right after which it misses for some conversions. I'll upload with delay between the two commands. Hmm framework i gotta give a shot :/ Sounds interesting ...
Solid script! Should make deodexing A LOT easier
Ok so i uploaded with delay between, seems to work fine, tested a LOT of times
thanks for this! can't wait for frameworks to be de-odexed.
jubeh: Thanks for the info. I had no idea and have informed JF previously here: http://jf.andblogs.net/2009/11/08/smalibaksmali-v1-0/ (see comments)
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!!!
I've ran through default.xml and made some changes allowing me to access hotspot and turn it on but I cannot get any data to transfer.. anyone figure this out yet?
It should be the same as on previous devices - the APNs will need to be updated to add the dun profile and cust_cdmaconn.dat will probably need to be removed (in addition to the default.xml changes to which you refer).
Captain_Throwback said:
It should be the same as on previous devices - the APNs will need to be updated to add the dun profile and cust_cdmaconn.dat will probably need to be removed (in addition to the default.xml changes to which you refer).
Click to expand...
Click to collapse
Thanks capt'n! Where can I find information on how to update APN to add dun profile? I have the paid version of root explorer and nothing came up when I searched for cust_cdmaconn.dat
edit:
found cust_cdmaconn.dat manually in system>customize but still need to update apn to add dun profile, not familiar with that, any help would be appreciated, thanks!
Captain_Throwback said:
It should be the same as on previous devices - the APNs will need to be updated to add the dun profile and cust_cdmaconn.dat will probably need to be removed (in addition to the default.xml changes to which you refer).
Click to expand...
Click to collapse
When I goto network settings on my a9 Access point names is grey'd out :/ and i cannot access it. Im rooted lastest 1.57 stock rom s-off if that matters..
Ive searched far and wide, adding to the build.prop does not work anymore:
ril.sales_code=LOL
ro.csc.sales_code=LOL
Update:
got MSL from sprint, went into ##data# and scoped the settings. Theyre different with new update I guess. There's no APN settings or anything of the sort showing default,mms. EHRPD only shows enable or disable and LTE only shows the same, enable or disable.
Can anyone shine some light on this?
wholigan423 said:
When I goto network settings on my a9 Access point names is grey'd out :/ and i cannot access it. Im rooted lastest 1.57 stock rom s-off if that matters..
Ive searched far and wide, adding to the build.prop does not work anymore:
ril.sales_code=LOL
ro.csc.sales_code=LOL
Update:
got MSL from sprint, went into ##data# and scoped the settings. Theyre different with new update I guess. There's no APN settings or anything of the sort showing default,mms. EHRPD only shows enable or disable and LTE only shows the same, enable or disable.
Can anyone shine some light on this?
Click to expand...
Click to collapse
When I referred to editing the APN, I meant doing it in framework-res.apk, by decompiling it.
Obviously if you do that you'll need to have a stock system image backup made and dm-verity disabled otherwise your system won't boot.
Captain_Throwback said:
When I referred to editing the APN, I meant doing it in framework-res.apk, by decompiling it.
Obviously if you do that you'll need to have a stock system image backup made and dm-verity disabled otherwise your system won't boot.
Click to expand...
Click to collapse
... perhaps this is over my head but as im sure im not alone, if this could be explained in greater detail im sure more people would greatly appreciate and even maybe script into a easy program, other than myself
wholigan423 said:
... perhaps this is over my head but as im sure im not alone, if this could be explained in greater detail im sure more people would greatly appreciate and even maybe script into a easy program, other than myself
Click to expand...
Click to collapse
Not sure what else you want me to explain. Decompile the framework and add the dun profile to the standard CDMA (LTE and eHRPD) APNs. If there's a dun only APN, remove it. If you remove the read-only flag, you should be able to view the APNs in Settings.
As far as the dm-verity flag, that's explained a bit more in the TWRP thread, and I provided a boot image patches to take care of that already.
All of the tools you need can be found using search. Welcome to XDA-Developers .
Captain_Throwback said:
Not sure what else you want me to explain. Decompile the framework and add the dun profile to the standard CDMA (LTE and eHRPD) APNs. If there's a dun only APN, remove it. If you remove the read-only flag, you should be able to view the APNs in Settings.
As far as the dm-verity flag, that's explained a bit more in the TWRP thread, and I provided a boot image patches to take care of that already.
All of the tools you need can be found using search. Welcome to XDA-Developers .
Click to expand...
Click to collapse
Let me know if im on the right track..
So I've flashed the Dm verify via TWRP and Im viewing the androidmanifest.xml in the framework-res.apk-----about 2/3s the way down (viewing on phone root explorer) youll find
<permission>
name="android.permission.WRITE_APN_SETTINGS"
protectionlevel="18">
</permission>
It appears most of the items are regulated between 2 or 18. So would I be correct to assume that changing this 18 to a 2 would allow me access to the native APN settings in phone?
wholigan423 said:
Let me know if im on the right track..
So I've flashed the Dm verify via TWRP and Im viewing the androidmanifest.xml in the framework-res.apk-----about 2/3s the way down (viewing on phone root explorer) youll find
name="android.permission.WRITE_APN_SETTINGS"
protectionlevel="18">
It appears most of the items are regulated between 2 or 18. So would I be correct to assume that changing this 18 to a 2 would allow me access to the native APN settings in phone?
Click to expand...
Click to collapse
Nothing you need to edit is in the manifest. You need to edit the actual APNs, which are found in res/xml.
EDIT: Actually I don't know if changing that value will allow you to change the APN Settings. I've never figured out how to change the manifest successfully.
Captain_Throwback said:
Nothing you need to edit is in the manifest. You need to edit the actual APNs, which are found in res/xml.
EDIT: Actually I don't know if changing that value will allow you to change the APN Settings. I've never figured out how to change the manifest successfully.
Click to expand...
Click to collapse
OK so now im viewing the cdmaapn.xml and added dun to all the profiles, is that all? can I add it into the framework-res.apk directly overwriting on system?
also edited apns.xml and added dun to profiles
now how do i get them into the framework-res.apk? Can I use root explorer and copy/paste them directly in?
wholigan423 said:
OK so now im viewing the cdmaapn.xml and added dun to all the profiles, is that all? can I add it into the framework-res.apk directly overwriting on system?
Click to expand...
Click to collapse
Not sure I understand your last question. You should be able to recompile the apk, and then just drop the already compiled, modified apns into the original stock framework. That'll give you the updated APNs.
Then you'll have to delete the current telephony database in /data/data/com.android.providers.telephony/databases and possibly the shared_prefs folder if there are APNs in it.
im having an exceptionally difficult time re-compiling, most of the write ups seem out of date :/ uhg
Ive installed android sdk and latest java 64bit
heres the scirpt errors:
C:\Users\Mike\Downloads\adb-tools-1.0.31>apktool b frameworkzzz edited framework-res.apk
I: Using Apktool 2.0.0-RC2 on frameworkzzz
Exception in thread "main" brut.androlib.AndrolibException: brut.directory.DirectoryException: java.io.FileNotFoundException: frameworkzzz (The system cannot find the file specified)
at brut.androlib.Androlib.readMetaFile(Androlib.java:247)
at brut.androlib.Androlib.build(Androlib.java:266)
at brut.androlib.Androlib.build(Androlib.java:258)
at brut.apktool.Main.cmdBuild(Main.java:240)
at brut.apktool.Main.main(Main.java:89)
Caused by: brut.directory.DirectoryException: java.io.FileNotFoundException: frameworkzzz (The system cannot find the file specified)
at brut.directory.ZipRODirectory.<init>(ZipRODirectory.java:54)
at brut.directory.ZipRODirectory.<init>(ZipRODirectory.java:37)
at brut.androlib.res.util.ExtFile.getDirectory(ExtFile.java:55)
at brut.androlib.Androlib.readMetaFile(Androlib.java:243)
... 4 more
Caused by: java.io.FileNotFoundException: frameworkzzz (The system cannot find the file specified)
at java.io.RandomAccessFile.open0(Native Method)
at java.io.RandomAccessFile.open(Unknown Source)
at java.io.RandomAccessFile.<init>(Unknown Source)
at org.apache.commons.compress.archivers.zip.ZipFile.<init>(ZipFile.java:203)
at org.apache.commons.compress.archivers.zip.ZipFile.<init>(ZipFile.java:182)
at org.apache.commons.compress.archivers.zip.ZipFile.<init>(ZipFile.java:143)
at brut.directory.ZipExtFile.<init>(ZipExtFile.java:28)
at brut.directory.ZipRODirectory.<init>(ZipRODirectory.java:52)
... 7 more
wholigan423 said:
im having an exceptionally difficult time re-compiling, most of the write ups seem out of date :/ uhg
Ive installed android sdk and latest java 64bit
heres the scirpt errors:
C:\Users\Mike\Downloads\adb-tools-1.0.31>apktool b frameworkzzz edited framework-res.apk
I: Using Apktool 2.0.0-RC2 on frameworkzzz
Exception in thread "main" brut.androlib.AndrolibException: brut.directory.DirectoryException: java.io.FileNotFoundException: frameworkzzz (The system cannot find the file specified)
at brut.androlib.Androlib.readMetaFile(Androlib.java:247)
at brut.androlib.Androlib.build(Androlib.java:266)
at brut.androlib.Androlib.build(Androlib.java:258)
at brut.apktool.Main.cmdBuild(Main.java:240)
at brut.apktool.Main.main(Main.java:89)
Caused by: brut.directory.DirectoryException: java.io.FileNotFoundException: frameworkzzz (The system cannot find the file specified)
at brut.directory.ZipRODirectory.<init>(ZipRODirectory.java:54)
at brut.directory.ZipRODirectory.<init>(ZipRODirectory.java:37)
at brut.androlib.res.util.ExtFile.getDirectory(ExtFile.java:55)
at brut.androlib.Androlib.readMetaFile(Androlib.java:243)
... 4 more
Caused by: java.io.FileNotFoundException: frameworkzzz (The system cannot find the file specified)
at java.io.RandomAccessFile.open0(Native Method)
at java.io.RandomAccessFile.open(Unknown Source)
at java.io.RandomAccessFile.<init>(Unknown Source)
at org.apache.commons.compress.archivers.zip.ZipFile.<init>(ZipFile.java:203)
at org.apache.commons.compress.archivers.zip.ZipFile.<init>(ZipFile.java:182)
at org.apache.commons.compress.archivers.zip.ZipFile.<init>(ZipFile.java:143)
at brut.directory.ZipExtFile.<init>(ZipExtFile.java:28)
at brut.directory.ZipRODirectory.<init>(ZipRODirectory.java:52)
... 7 more
Click to expand...
Click to collapse
Update your apktool. You should be using the latest version to both decompile and recompile the APK for best results.
Captain_Throwback said:
Update your apktool. You should be using the latest version to both decompile and recompile the APK for best results.
Click to expand...
Click to collapse
Thanks, you've been a great deal of help. Now I just need to figure out how the hell to open this damn .jar file on windows 10 fml
I take it there isn't and won't be an easier way to do this.
Okay... So decompile framework-res.apk which is located in /system/framework. Navigate to res/xml. Edit apns.xml and add dun to the APNs and delete the dun APN if it is there. At this point do I have to sign the APK (it has been a long time since I've done any tinkering with APKs)? And then I push the APK back to /system/framework and chmod 644 it. Should I reboot into recovery at this point and wipe data? Or do I just have to reboot the phone and delete the current telephony database?
Or could I just recompile the APK, and then just extract the modified apns.xml from the recompiled APK and just insert the apns.xml into the stock APK?
truthfuldemise said:
Okay... So decompile framework-res.apk which is located in /system/framework. Navigate to res/xml. Edit apns.xml and add dun to the APNs and delete the dun APN if it is there. At this point do I have to sign the APK (it has been a long time since I've done any tinkering with APKs)? And then I push the APK back to /system/framework and chmod 644 it. Should I reboot into recovery at this point and wipe data? Or do I just have to reboot the phone and delete the current telephony database?
Or could I just recompile the APK, and then just extract the modified apns.xml from the recompiled APK and just insert the apns.xml into the stock APK?
Click to expand...
Click to collapse
good luck man i still havent got it 1 week in to tinkering, update us if you get plz thanks
I didn't have any trouble decompiling or recompiling the framework-res with the latest apktool, so I'm not sure why you were having issues.
I'm attaching a zip with the updated framework-res.apk in it, from the latest Sprint RUU that was available on HTC's website (1.57.651.1). While it is technically a flashable zip, I couldn't test it, so if it doesn't work, you might just be better off replacing the file manually and deleting the other files while in TWRP.
I have two asserts in the zip - one will confirm you're flashing the zip to a Sprint device, and the other will read your baseband to ensure you're on the latest firmware/software before allowing you to flash. The latter assert I'm not positive about, so if you're certain you're on the latest and the zip won't flash, I'll need a recovery log.
Additionally, I don't even know for sure whether these changes will allow tether to work on this device. So absolutely make sure you make a backup before flashing this!
Captain_Throwback said:
I didn't have any trouble decompiling or recompiling the framework-res with the latest apktool, so I'm not sure why you were having issues.
I'm attaching a zip with the updated framework-res.apk in it, from the latest Sprint RUU that was available on HTC's website (1.57.651.1). While it is technically a flashable zip, I couldn't test it, so if it doesn't work, you might just be better off replacing the file manually and deleting the other files while in TWRP.
I have two asserts in the zip - one will confirm you're flashing the zip to a Sprint device, and the other will read your baseband to ensure you're on the latest firmware/software before allowing you to flash. The latter assert I'm not positive about, so if you're certain you're on the latest and the zip won't flash, I'll need a recovery log.
Additionally, I don't even know for sure whether these changes will allow tether to work on this device. So absolutely make sure you make a backup before flashing this!
Click to expand...
Click to collapse
sweet, thanks, im testing now. and I already have the latest 1.57.651.1 RUU direct from htc website, but i ran it in twrp and attempted to flash the zip and "error: 7" came up something like your system is old and out of date, but I most definetly have the latest. So now I am extraction in root explorer and gonna over write framework-res.apk with new one...here it goes...lol. DONT do it while your phone is on. NEEDS to be done on computer. instant restart, hopefully not bricked. will update after im done panicking. (i have backed up system just incase but still...)
wholigan423 said:
sweet, thanks, im testing now. and I already have the latest 1.57.651.1 RUU direct from htc website, but i ran it in twrp and attempted to flash the zip and "error: 7" came up something like your system is old and out of date, but I most definetly have the latest. So now I am extraction in root explorer and gonna over write framework-res.apk with new one...here it goes...lol. DONT do it while your phone is on. NEEDS to be done on computer. instant restart, hopefully not bricked. will update after im done panicking. (i have backed up system just incase but still...)
Click to expand...
Click to collapse
I asked for a recovery log if the flash failed....
And flashing the zip assumes you've already removed encryption and patched your boot.img. I thought those were givens.
EDIT: I can incorporate the boot.img patches into the zip, but won't be able to delete the telephony database, since TWRP can't by default decrypt /data. So then you wouldn't be using the updated APNs, which would make the changes useless.
EDIT 2: And you can replace the framework-res directly on the phone - you just have to do it while in TWRP. That's how I make most edits to my devices.
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.