I am trying to make a modified /system/app/NfcNci.apk , but when I load it on the device, I get the below error. What do I have to do to build to fix this? This is on a rooted stock Nexus 4. I built apk using standard google source, and pushed file over using adb. Thanks.
Code:
W/PackageManager( 529): Signature mismatch for shared user : SharedUserSetting{4182adf0 android.uid.nfc/1027}
E/PackageManager( 529): Package com.android.nfc has no signatures that match those in shared user android.uid.nfc; ignoring!
CptanPanic said:
I am trying to make a modified /system/app/NfcNci.apk , but when I load it on the device, I get the below error. What do I have to do to build to fix this? This is on a rooted stock Nexus 4. I built apk using standard google source, and pushed file over using adb. Thanks.
Code:
W/PackageManager( 529): Signature mismatch for shared user : SharedUserSetting{4182adf0 android.uid.nfc/1027}
E/PackageManager( 529): Package com.android.nfc has no signatures that match those in shared user android.uid.nfc; ignoring!
Click to expand...
Click to collapse
This thing comes when the target device contains apk/dex(odex) file with a different signature, which is normaly due to the fact that the app is build by some others, or some other adk. Or any other adk other than yours( i mean the one u used to create ur modified apk).
The solution goes like this,
Uninstall the apk, and remove its odex(dalvic cache ), if its a system apk, use root access to do it.
If its a critical app( which will turn of ur device if u delete it, like phone apk etc) create a recovery flashable zip of ur apk, go to recovery, wipe cache, dalvic cache, and flash ur zip.( remember to rename the apk exactly as it is in ur device, else it wont replace the original one, also set appropriate permissions). Reboot.
Dissable signature verification by patching core.jar ( lucky patcher application can do the trick for u). But its not recomended, unless u know what it is and what it can.
Sent from my HD2 using xda premium
Thanks I ended up fixing this by just copying the AndroidManifest.xml and the INF directory from the original apk into my modified one and it worked.
showlyshah said:
This thing comes when the target device contains apk/dex(odex) file with a different signature, which is normaly due to the fact that the app is build by some others, or some other adk. Or any other adk other than yours( i mean the one u used to create ur modified apk).
The solution goes like this,
Uninstall the apk, and remove its odex(dalvic cache ), if its a system apk, use root access to do it.
If its a critical app( which will turn of ur device if u delete it, like phone apk etc) create a recovery flashable zip of ur apk, go to recovery, wipe cache, dalvic cache, and flash ur zip.( remember to rename the apk exactly as it is in ur device, else it wont replace the original one, also set appropriate permissions). Reboot.
Dissable signature verification by patching core.jar ( lucky patcher application can do the trick for u). But its not recomended, unless u know what it is and what it can.
Sent from my HD2 using xda premium
Click to expand...
Click to collapse
Related
NOTE: DO NOT DO THIS UNLESS YOU KNOW WHAT YOU ARE DOING, YOU CAN EASILY SCREW UP YOUR SYSTEM, AND THIS WON'T HELP YOU.
BACKUP FIRST, AND MAKE SURE YOU HAVE A SETUID SH AS ROOT SO YOU CAN RECOVER FROM BACKUPS IF NECESSARY.
First you have to re-sign framework-res.apk using testkeys. This will allow you to use testkeys for system uid packages.
Next step is to re-sign all other apks that use shared uid system.
That is: bootinfo, Fota, GoogleCheckin, GoogleSubscribedFeedsProvider, NetworkLocation, ServiceMenu, Settings, SettingsProvider, VpnServices
Next you have to re-sign all apks that use the platform key, which turns out to be the shared uid phone - these require implicit permissions from the platform like DEVICE_POWER:
TelephonyProvider, Stk, semc-backup-rachael, Phone
Finally, I think GoogleEnhancedSearch also needs it or something otherwise a settings menu will fc.
The nice part about re-signing is that you don't actually need to deodex the files.
One important thing is that in the new versions, the fota.action.DEBUG_ENTRY is actually disabled, and moreover, requires special permissions that aren't granted. This is where re-signing comes in.
Now, you need to deodex fota.apk, modify the manifest to remove permissions required for DEBUG_ENTRY, and finally, force enable the debug menu:
In com/sonyericsson/android/fota/common/fotaview/FotaDebugEntry.smali,
find "debug UI is not available!"
a few lines above, there is if-nez v0 :cond_0
change it to if-eqz v0 :cond_0
This forces it to enable the debug menu.
Now we re-smali the Fota.apk, re-sign, then push it on to the phone along with the rest of the modified packages.
Repush all the files to the phone and it's done
problem !
baksmali gives an error at fota.apk
can you post your deodex scrypt
Why is this required?
TechGuru_x10 said:
Why is this required?
Click to expand...
Click to collapse
So that you won't have to keep re-flashing the older firmware to root (and keep re-installing stuff afterwards), and it should save time in repairing your firmware if you mess system files up.
It should also allow us to upgrade to newer firmwares from the current one, so we don't have to lose all of our apps/settings when rooting our phones again with a newer firmware.
Is this right guys? Anyway, thanks and good luck!
jerpelea said:
problem !
baksmali gives an error at fota.apk
can you post your deodex scrypt
Click to expand...
Click to collapse
You need to add the classpath by deodexing everything in the framework folder and including it.
zephyrix said:
You need to add the classpath by deodexing everything in the framework folder and including it.
Click to expand...
Click to collapse
oki
will try
thanks
found my error
i was using smali1.2.2 tested with 1.2.3 and is working
jerpelea said:
oki
will try
thanks
found my error
i was using smali1.2.2 tested with 1.2.3 and is working
Click to expand...
Click to collapse
Could these steps be made into a script, to run everything at once? Or at least in sections?
Daneshm90's autodeodexer 2.3 modified by me for X10
http://hotfile.com/dl/53736770/16a1bc8/Deodexer_2_3_SE.rar.html
So eventually (with this) we can take a newer build and run this script thus allowing us to then run the files necessary for root?
what do you mean by newer builds like R2BA020
Sorry if Im being a noob but lets say I mess up a framework file and get stuck at the bootscreen. When I try to use adb to push my backup it says permission denied. Will this allow me to make the changes?
Well what I've done is use a modified adb which runs as root and replaces on boot. However, I believe you could use a setuid sh and achieve the same result.
i.e. cp /system/bin/sh /system/bin/rootsh
chmod 6755 /system/bin/rootsh
then you can push to a folder where you can normally write, and use rootsh and move it.
Great thanks, I'm going to wait until I have to try it...
Is anyone else experiencing difficulty with the Kitchen in this version? None of the kitchen tweaks will work, they download fine, and it goes thru the regular process of installing, however none of the programs seem to be functioning after installation. Just checking with anyone else before I try re flashing. I did do a full wipe before install.
2.3.6
xxki4
Siyah 2.3
Checkrom V4
The same thing is happening with me. It downloads the files just fine but when it tries to install them, it restarts to the wrong recovery (not clockworkmod). You can see the things fail installing because of the <!> that comes up in the recovery for a split second.
How can we get it working? The only way I've done it is to manually restart to the right recovery, and then manually install each zip.
Reinstall the kitchen app
Sent from my GT-I9100 using xda premium
Try installing them from recovery, you have to delete or rename the clockworkmod folder on the external sd card in order to install things directly from the kitchen.
Sent from my GT-I9100 using Tapatalk
Some of the mods might not work if the kernel is incompatible to those specific mods
Sent from my GT-I9100 using xda premium
salted_hash in clockworkmod folder
Found the culprit:
Q: I am not able to flash via Kitchen???
A: Delete Clockworkmod folder
Reason:
Previously to make the kitchen flash in older version of CWM5 we need to use a salte hash file that was placed in the Clockworkmod folder, Now with the updated CWM5 the actually problem with CWM5 was fixed by the respective creator!
So now what happens is that all you people have that salted hash file remaining in ur sd card that doesn't allow to flash stuff in the newer better CWM5, thats why when u delete the Folder it stats working coz the salted hash file gets deleted!
Now you may ask why delete the folder, when u can delete the file only!!
LOL answer is simle the Android os never recognizes the file there so when u open myfiles you never find the salted hash file inside the clockworkmod folder! You can use other apps and methods to delete the file but then there is the obvious questions from noobs!!
So Moral the problem is only with that one salted hash file and not ur backup.
Click to expand...
Click to collapse
So you can delete the entire folder, or just the "/sdcard/clockworkmd/.salted_hash" file. This worked for me.
Correct just the salted hash needs to go, there's no need to lose your backups. If you do delete the folder next time you do a nandroid it will only get recreated without the salted hash.
Sent from my GT-I9100 using Tapatalk
Just to check with you guys. is there any wipe of checkrom available?it appears that there is only the no-wipe version.
whenever i add a new '.so' file ( like libstagefright.so, libc.so,,) then the tab (GT P1000) reboots in a loop. what is the reason for this ?
the steps i followed to build '.so' files are.
i got root access in the tab by modifying the default.prop file
i have busybox ( /sbin/busybox)
then downloaded the source cm7sg from git hub. and built the gingerbread for cyanogen_galaxytab
then in recovery mode ,i used adb to push the cm7sg/out/target/product/galaxytab/system/lib/libstagefright.so to the tab
then the system reboots in a loooop................
U dont write about it: Did u give permissions (rw-r-r) for this files?
Sent using r800i with DoomKernel v11 (1.21ghz)
yes , the permission is the same ..
I'm not into lib files, so i think that only thing i can do to help u is giving this link: http://forum.xda-developers.com/showthread.php?t=1525226.
It's a beatsaudio port. Inside .zip are some .so files which are working without bootloops, so i think that they need to do sth to make it working. Maybe u can find sth there
Any integrity checking mechanism for library files (libstagefright / libc) during initialization time such as signature validation, CRC checking, size checking etc?
Is there a way to modify cyanogenmod before I install it, so that after the installation, is already configured with my settings/preferences?
NucleusMS said:
Is there a way to modify cyanogenmod before I install it, so that after the installation, is already configured with my settings/preferences?
Click to expand...
Click to collapse
i dont think the same is posible before installing the same(Cynogenmod) for sure
Settings are stored at data partition in db files, so you can modify the zip, include those files into it and modify updater-script. After that, flash the zip, and your settings should be.
But I do not recommend to do this, because you can end with a bootloop.
Anyway, what's the problem to set the phone again? That's only 2 minutes.
Hi everyone,
I want to eventually create an edited ROM for an Android tablet. (Very simple stuff, really. Removing apks, adding build.prop mods)
I have a working update.zip file, which re-installs the image on the tablet, through stock recovery and the install from sdcard option.
But once I unzip it,
and then zip and even re-sign it (with the tool I found by searching the forum),
the recovery says 'installation aborted', when it is verifying the package.
1. How can I avoid this from happening? I get it that closing the update.zip is done wrong. How can I pass the verification section?
2. It IS possible to push such a .zip through stock recovery, right? I want to avoid CWM and TWRP and make it as simple as possible.
Thanks.
Have you tried making the changes without the unzip-rezip step? Editing the zip contents directly inside the zip (just drag n drop, delete, etc).
dxppxd said:
Have you tried making the changes without the unzip-rezip step? Editing the zip contents directly inside the zip (just drag n drop, delete, etc).
Click to expand...
Click to collapse
I tried this, too.
I only deleted one apk from system/app and later I tried again by deleting the apk and its odex file, too.
In both cases, instead of rejecting the update instanlty, it starts the process and then stops after a few seconds.
IS it possible that there is a filesize checker text inside the image?
(or maybe a propery inside the build.prop or updater-script ?)
Any ideas, anyone?
Still no progress.
I am trying to avoid custom recovery,
(I guess that would involve re-compiling it - which I do not know how to do - or ... just asking so from someone?)
is it possible to push the update.zip through stock recovery?
iraklisvel said:
Still no progress.
I am trying to avoid custom recovery,
(I guess that would involve re-compiling it - which I do not know how to do - or ... just asking so from someone?)
is it possible to push the update.zip through stock recovery?
Click to expand...
Click to collapse
No
Stock recovery doesn't flash custom roms
Get cwm from builder.recovery.com
Press thanks :good: I'd helped :highfive: