yashsingh1/xdaforums huggingface dataset:
[Android] dsixda:
Just remove these lines from do_deodex_file:

elif [ "$odex_file" == "HtcFootprints.odex" ] || \
[ "$odex_file" == "HtcLocationPicker.odex" ] || \
[ "$odex_file" == "Weather.odex" ]
then
classfile=com.google.android.maps.jar

elif [ "$odex_file" == "GmailProvider.odex" ] || \
[ "$odex_file" == "gtalkservice.odex" ] || \
[ "$odex_file" == "Talk.odex" ] ||
[ "$odex_file" == "Vending.odex" ]
then
classfile=com.google.android.gtalkservice.jar

Thanks
[Android] t2noob:
I used these scripts and i still can't log onto google.

if you need anything let me know.
[Android] dsixda:
Just follow this post, thanks.

http://xdaforums.com/showpost.php?p=7212111&postcount=1140
[Android] t2noob:
Here you go this is the boot process all the way to me getting the error and not being able to sign into google.

http://pastebin.com/Yg9vYhYU
[Android] nerdo:
A2SD not working on Desire

@dsixda

Just outstanding work... hat off :D

Been referring loads of people to this thread!

I've read a couple of pages back that A2SD wasn't working on Legend

I can confirm the same for Desire... any one with ideas/clues on how to fix this?
[Android] rfgamaral:
I tried this and here's a couple of remarks...

a) The footprints and weather odex files don't need the above check, they deodex just fine without it. However, the location picker does need it. Lots of errors occur and the script will end up using com.google.android.maps.jar anyway.

b) The rest of lines you asked me to remove, I don't even understand what they are doing there... Those .odex files don't even exist in the first place, so there's nothing to deodex.

c) There's a bunch of .apk files on the /system/app folder that don't have (by default) a matching .odex file, some of which you are checking if they exist (point b). These files don't seem to be signed at all, maybe they should be signed with the same key that everything else was signed with...

d) Your suggestion above didn't work unfortunately... Here's a logcat though, since the start of the first booting process up until it failed the login attempt: http://pastebin.com/S5U9w05h

You reported something like this before:

W/dalvikvm( 312): Refusing to reopen boot DEX '/system/framework/com.htc.framework.jar'

But it also happens for this file:

W/dalvikvm( 473): Refusing to reopen boot DEX '/system/framework/com.htc.android.pimlib.jar'
[Android] dsixda:
At line 408 it gets to framework-tests.jar and complains about some LockPatternKeyguardViewTest. I had this problem before and it was because framework/framework-res.apk was not signed. However, if you had deodexed the app folder then the script already goes to the framework folder to sign that file.

Did you have any APKs in framework or app folder (other than framwork-res.apk) that didn't have any ODEX files?
[Android] rfgamaral:
No I did not...
[Android] Yay 4 Juggs:
Silly question now that you brought this up...i thought if we signed the update we didnt have to sign each apk seperately? I have a heavily modified framework and resource apk that i signed prior to putting them into the build...So my question is this...could there be something wrong in the way the kitchen signs the update that is causing the problem? I ask because although my personal rom does not have these problems im getting reports of users who flashed my public rom are having sense fc issues at boot.
[Android] Yay 4 Juggs:
just duplicated the sense fc after flashing my public rom...
[Android] rfgamaral:
I'm getting kinda tired trying to make this work :(

Maybe there's more to deodexing than to just convert an .odex file into classes.dex and put it inside the .jar/.apk...

I'm not sure what try next :S
[Android] dsixda:
If you're changing to a custom ROM that uses a different base ROM from your previous one, then you may need to do a wipe before flashing.

Someone else had Sense issues, I think he solved it though. Apps2sd?
[Android] dsixda:
Me too, I'm getting tired of this but I really want to get this working; not good to have an unfinished product.
[Android] dsixda:
You need to sign the ROM with the same keys as the APKs you signed during deodexing or themeing.

If you didn't do any deodexing, then you just need to sign the finished ROM.

But yeah, there is definitely a problem with signing, somewhere, due to the error shown in the pastebin.
[Android] Yay 4 Juggs:
they both came from the same stock base which is weird how mine works on my phone but when i built from my nandroid backup got the sense error after a full wipe...
[Android] dsixda:
Sorry, dammit, I didn't see this post of yours. Ok, if there are APKs *without* andy ODEX files then they definitely need to be signed! My script didn't check for remaining files.

I'll put a final check to make sure ALL apk's are signed.
[Android] dsixda:
That's strange because the Desire ROM I have uses those dependencies. The errors are fine, because the script is employing the brute-force method (it will go through all .jar files to finally find its match).

That's fine, some ROMs will require those. In fact I could take out everything in there because the brute force method would take over, but then it would take longer time.
[Android] dsixda:
Ok, please try the following attachment. This will make sure ALL *.apk under the /system/framework and /system/app folders are signed after deodexing.
[Android] Yay 4 Juggs:
just built and tried to flash...first time i got this error

E:Wrong digest:

system/app/phone.apk

E:Verification failed

Installation aborted
[Android] Yay 4 Juggs:
ok cleaned out everything...went thru with and got a settings error...com.android.settings has stopped unexpectedly...and "no service" going to try and resign settings apk manually
[Android] dsixda:
Was there a phone.odex in the original ROM?
[Android] Yay 4 Juggs:
no it was calkulins deodexed stock root
[Android] dsixda:
Then why did you download the new files if you don't need to deodex? Nothing has changed otherwise. We need someone to test the deodexing on their device.
[Android] Yay 4 Juggs:
because im testing both...one kitchen has deodexed the other has odexed files...im doing it this way for comparison purposes
[Android] Yay 4 Juggs:
now getting fc on htcsetupwizard...
[Android] dsixda:
If you're not deodexing then please try not to put any more comments because it is moving the new attachments further back into the post. There's nothing I can do about your problem if it has nothing to do with deodexing.
[Android] puertoblack2003:
CONGRATULATIONS !!!!!!!!! :D you have solve the issue for the deodexed issue for the htc evo.I confirm that everything is working including signing on to googles, facebook and twitter.You deserve a nice hot cup of coffee later :)
[Android] shelnes:
Great work :)

Kitchen working perfectly! But is it a way to add auto apps2sd? Solutions to this is very welcome
[Android] mr.bang:
if u haven't required libraries u must find them! so u can correctly compile mkbootimg!
[Android] mr.bang:
it is simple but u have to wait changes by dsixda! he is the kitchen dev!
[Android] dsixda:
Hi! Yes, I wanted to do this for the next release; unfortunately my next couple of days will be busy with guests.

Here is some info on it:

http://lukasz.szmit.eu/2009/12/making-your-own-rooted-android-rom.html

Jump to this section: Step 4 - Modifying the boot image ramdisk

You will need to extract the contents of boot.img from the kitchen, and then manually modify the files in the BOOT-EXTRACTED folder with the commands the guy mentioned in his page.
[Android] shelnes:
I'll take a look at it! But there's no rush. Just flashed the rom, and it seems great :) Thank you for your good job on the kitchen
[Android] dsixda:
You're welcome, let me know if you have any issues and/or more suggestions!
[Android] shelnes:
Yeah, I'll do that. But haven't got the time before tomorrow. Need to go to soccer practice first and I'm working tonight. Hopefully it will be a quiet night and then I might even do it tonight
[Android] dsixda:
Ok I got Apps2SD working.. haha, but i need someone to test it. I just followed the instructions in the link I provided above.
[Android] RichardFHTC:
Can I ask a couple of questions

If you are taking other update.zips for example clearit or nexus boot screen

Can I just copy the files over and replace the original ones, or do I also copy across the files in the meta folder as well ? or do I run option 8 and run the update script somehow on the working folder

cheers
[Android] shelnes:
Damn, you're fast :) apps2sd working fine
[Android] dsixda:
Good question. You can overwrite the files that are currently in your working folder. However, you will need to merge the contents of the new 'update-script' file (under META-INF/com/google/android/) with the update-script that is currently in your working folder.
[Android] RichardFHTC:
thanks for getting back so for example I have moved boot screen images from nexus boot screen and placed in same folder in working folder. I then copy all contents from the meta-inf folder to the same place in working folder, including .rsa .sa and manifest.mf files, then merge information in file you have stated in this case

show_progress 0.1 0

copy_dir PACKAGE:system SYSTEM:

show_progress 0.1 10

If i want to do this for more than one package do I then have to start merging these files as well .rsa .sa and manifest.mf, will that work

thanks again
[Android] dsixda:
Sorry, forgot to say, don't include those 3 cert/manifest files under META-INF. Those actually get created when you sign your update.zip.

Regarding update-script, if the stuff above is already found in your working folder's update-script, then you don't need to add that. Just merge stuff that isn't already there.

Hopefully soon I can make an option to make it easy to merge update-script at the correct places in the file.
[Android] dsixda:
Sorry guys, just made a small typing error in the Menu.

In Step 7, where it says "build new boot.img", it should say "for Option 6" instead of "for Option 5".

I've updated the ZIP file if you don't want to make the change to the 'menu' script yourself.
[Android] RichardFHTC:
looking at other update files they are just copy batch scripts right like windows eg

copy_dir PACKAGE:app SYSTEM:app copy_dir PACKAGE:framework SYSTEM:framework

if i have already moved this data manually this makes these lines not needed for update.script right.

In what instance would I actually have to add data to the update.script to get something to work

It is starting to make sense after alot of reading bit different to doing WM roms but is giving me chance to learn linux and android

cheers again :)
[Android] idflood:
I installed the teknologist kernel and had to add some lines to the update.script to have all the benefits. ( hxxp://android.teknologism.org/Download/ )

I'm giving up with mac. I have no errors while cooking but the rom won't boot. If someone has ideas of how to spot the bug I would be pleased to give it another try, but for now cooking on ubuntu with virtualbox is just easier...
[Android] dsixda:
I'm not an expert on update-script yet, but yeah, it's like a batch script. So if you have files that are already in their correct place then you don't need to mention them. However, if you made a mistake in the update-script (e.g. where the file was already copied even though you mentioned it in the update-script), it will tell you about the error while you're flashing the update.
[Android] aniceone:
File rights?

Hi

First, thanks for your great work!

I would like to try out your kitchen and I am quite new to the world of Linux(Ubuntu).

Currently running Ubuntu 9.10 on a virtual machine and have set it up using your directions in the first post.

When I first tried to run the script "menu" I got a error "unknown command" so I made it executable by typing

chmod u+x menu

then launched menu with

sudo ./menu

and the menu popped up in terminal.

But when i try the first option to set up a working directory the following appear

Found img_files/system.img
Found img_files/boot.img

Building working folder WORKING_021810_234948 ...

Copying update-script ...

Copying boot.img ...

Extracting contents of system.img ...
scripts/make_kitchen: rad 109: ../../tools/unyaffs: Access denied

Deleting symbolic links (don't worry if files are missing) ...
scripts/make_kitchen: rad 122: ./deleteextras: Access denied

Listing of WORKING_021810_234948:
totalt 1760
-rw-r--r-- 1 root root 1794048 2010-02-18 23:49 boot.img
drwxr-xr-x 3 root root 4096 2010-02-18 23:49 META-INF
drwxr-xr-x 2 root root 4096 2010-02-18 23:49 system

Done setting up kitchen!

Do I have to change permissions on every single file in the uncompressed directory? Or is it something that I am doing wrong?

Regards /D
[Android] dsixda:
Your operating system may have changed the permissions when you unzipped the files. I'll put up version 0.9 now, which will automatically change the permissions to 'executable' when you restart the menu.
[Android] mr.bang:
Sign on MAC

hi guys! i've completed the test for mac signing!

i used a script that make it simple!

to all Mac 10.3, 10.4 and 10.5 users:

download greatful modded jdk named SoyLatte!

http://blog.adsdevshop.com/2008/02/26/installing-the-jdk-16-on-mac-os-x/

to use the script:

mac# cd ./mac_signing/
mac# chmod +x ./sign_mac.sh

then

mac# ./sign_mac ARG_PATH

yay!
[Android] rfgamaral:
I'll test it out when possible, but it will take a while cause today I won't be in the computer until it's bed time. Sorry...

Just one thing though...

I did mention the fact that not

all

of the .apks were being signed in the /system/app folder but I also did compare the final deodexed files with the ones in the MoDaCo custom ROM (which is dedodex and fully working) and those .apks that don't have a matching .odex file, are exactly the same. I mean the files inside META-INF, the ones reponsible by signature hashes and the signature itself, are exactly the same. So, it shouldn't be needed to sign those .apks...

But I don't know, this is getting way to confusing for me...

Anyway, when possible, I'll test it and post the results, but it will take a while, maybe wait for tomorrow...
[Android] dsixda:
Awesome!! Now let's hope everything is working 100% ;)
[Android] dsixda:
No problem, thanks for all your assistance.

I have also read in one thread that you don't need to sign any files except the finished ROM, but JesusFreke had told me I needed to sign the APKs. Maybe I can test this out later on my Nexus One.
[Android] Yay 4 Juggs:
the way it ended up working for me with a full odex base was i had to manually sign the core apks within the system...however still not able to build a rom with using data/app as an option.
[Android] dsixda:
Yeah I was also wondering about data/app and whether those should be signed.

What happened with data/app?
[Android] Yay 4 Juggs:
it builds the files needed allows for input of apks but doesn't flash the apks...it's missing something when the permission is created. the folder and its contents are there but none of the apps get installed...
[Android] Yay 4 Juggs:
looking thru everything i have...nothing is telling the rom to flash from data/app...at all seems like its not creating the trigger
[Android] dsixda:
Post your update-script
[Android] Yay 4 Juggs:
Didnt write to the update script as it said it did...

Excerpt from add_data_to_update_script

perl -pi -e 's/show_progress 0.1 10/delete DATA:app\ncopy_dir PACKAGE:data DATA:\nset_perm 1000 1000 0771 DATA:app\n\nshow_progress 0.1 10/g' update-script

update_script

show_progress 0.1 0
format SYSTEM:
copy_dir PACKAGE:system SYSTEM:

symlink dumpstate SYSTEM:bin/bugreport
symlink dumpstate SYSTEM:bin/dumpcrash
symlink toolbox SYSTEM:bin/cat
symlink toolbox SYSTEM:bin/chmod
symlink toolbox SYSTEM:bin/chown
symlink toolbox SYSTEM:bin/cmp
symlink toolbox SYSTEM:bin/date
symlink toolbox SYSTEM:bin/dd
symlink toolbox SYSTEM:bin/df
symlink toolbox SYSTEM:bin/dmesg
symlink toolbox SYSTEM:bin/getevent
symlink toolbox SYSTEM:bin/getprop
symlink toolbox SYSTEM:bin/hd
symlink toolbox SYSTEM:bin/id
symlink toolbox SYSTEM:bin/ifconfig
symlink toolbox SYSTEM:bin/iftop
symlink toolbox SYSTEM:bin/insmod
symlink toolbox SYSTEM:bin/ioctl
symlink toolbox SYSTEM:bin/kill
symlink toolbox SYSTEM:bin/ln
symlink toolbox SYSTEM:bin/ls
symlink toolbox SYSTEM:bin/log
symlink toolbox SYSTEM:bin/lsmod
symlink toolbox SYSTEM:bin/mkdir
symlink toolbox SYSTEM:bin/mkdosfs
symlink toolbox SYSTEM:bin/mount
symlink toolbox SYSTEM:bin/mv
symlink toolbox SYSTEM:bin/netstat
symlink toolbox SYSTEM:bin/newfs_msdos
symlink toolbox SYSTEM:bin/notify
symlink toolbox SYSTEM:bin/printenv
symlink toolbox SYSTEM:bin/ps
symlink toolbox SYSTEM:bin/reboot
symlink toolbox SYSTEM:bin/renice
symlink toolbox SYSTEM:bin/rm
symlink toolbox SYSTEM:bin/rmdir
symlink toolbox SYSTEM:bin/rmmod
symlink toolbox SYSTEM:bin/route
symlink toolbox SYSTEM:bin/schedtop
symlink toolbox SYSTEM:bin/sendevent
symlink toolbox SYSTEM:bin/setconsole
symlink toolbox SYSTEM:bin/setprop
symlink toolbox SYSTEM:bin/sleep
symlink toolbox SYSTEM:bin/smd
symlink toolbox SYSTEM:bin/start
symlink toolbox SYSTEM:bin/stop
symlink toolbox SYSTEM:bin/sync
symlink toolbox SYSTEM:bin/top
symlink toolbox SYSTEM:bin/umount
symlink toolbox SYSTEM:bin/vmstat
symlink toolbox SYSTEM:bin/watchprops
symlink toolbox SYSTEM:bin/wipe
set_perm_recursive 0 0 0755 0644 SYSTEM:
set_perm_recursive 0 2000 0755 0755 SYSTEM:bin
set_perm 0 3003 06755 SYSTEM:bin/ip
set_perm 0 3003 02755 SYSTEM:bin/netcfg
set_perm 0 3004 02755 SYSTEM:bin/ping
set_perm 0 2000 06750 SYSTEM:bin/run-as
set_perm_recursive 1002 1002 0755 0440 SYSTEM:etc/bluetooth
set_perm 0 0 0755 SYSTEM:etc/bluetooth
set_perm 1000 1000 0640 SYSTEM:etc/bluetooth/auto_pairing.conf
set_perm 3002 3002 0444 SYSTEM:etc/bluetooth/blacklist.conf
set_perm_recursive 1002 1002 0755 0440 SYSTEM:etc/bluez
set_perm 0 0 0755 SYSTEM:etc/bluez
set_perm 1002 1002 0440 SYSTEM:etc/dbus.conf
set_perm 1014 2000 0550 SYSTEM:etc/dhcpcd/dhcpcd-run-hooks
set_perm 0 2000 0550 SYSTEM:etc/init.goldfish.sh
set_perm 0 0 04755 SYSTEM:etc/ppp/ip-up-vpn
show_progress 0.1 10

show_progress 0.2 0
write_raw_image PACKAGE:boot.img BOOT:
show_progress 0.2 10
[Android] dsixda:
Weird, I'll take a look later today. Thanks for the details.
[Android] Yay 4 Juggs:
seems no app2sda support being written in as well?

Creates the folder and placeholder but when trying to use it doesn't recognize the rom supporting it...
[Android] dsixda:
Here you go, this should be the fix, attached. Copy under scripts folder. If you have time, try it out; otherwise don't worry.. I've tested it on a couple of update-script files.
[Android] dsixda:
Can you use option 15 to extract your boot.img? Grab the file init.rc under the BOOT-EXTRACTED/ramdisk folder and upload it here.

Or you can just pull the file init.rc straight from under the root directory of your ROM.

Thanks
[Android] Yay 4 Juggs:
here ya go
[Android] rfgamaral:
I found a little time and I can say that it finally worked :)

I logged in to market, used MarketAccess and could see paid apps, which is nice. Everything seems to be working fine...

Now, fix those little problems Yay 4 Juggs is having and you're ready to release 0.68 :)
[Android] dsixda:
HA, great work.

Now, I just tried deodexing and flashing a ROM *without* signing a single APK and it flashed fine. I can log into Gmail, Calendar, and sync everything etc. Strange, so we don't need signing of APK??!?!!

I wonder what will happen in other ROMs?

Can someone try these two files in the attachment? Copy them to scripts folder and then deodex all over again. Thanks
[Android] rfgamaral:
Both in framework and app folder?

I'll give it a go later into the night, its 7:20 PM here, like midnight or later. I probably won't have a chance before than :p

But it's weird that you don't have to sign the apk files... You're adding a file (classes.dex) inside the .apk, it should need signing. But I don't know how everything works bit by bit so...

EDIT: I think I might understand what's going in here a little bit... Comparing with MoDaCo and Villain ROMs, they don't seem to sign their files either. The thing is, the MANIFEST.MF file has the "signatures" or "hashes" for each file inside the APK. Both in MoDaCo and Villain ROMs, the .apks with matching .odex (which now have the classes.dex inside it) doesn't have an "hash" for the classes.dex file inside the MANIFEST.MF file. While files that originally were not an .apk/.odex pair (for instance, GoogleProvider.apk) have the "hash" for the classes.dex file. So, the signatures between matching user ids must be same and if you sign some files you're probably better signing ALL OF THEM. Otherwise, just place the classes.dex file inside the APK and do not sign anything. The signatures for matching user ids will still be the same and everything will work. It's a little confusing, I myself don't understand every bit of it but bottom line is, either sign all of the APKs, or do not sign any of them. Both methods will probably work. Which is better? I don't know but I would probably go with signing everything. For future theming or hacking, this would force every one editing one of these files, to resign the APKs. Where if nothing was signed in the first place, the classes.dex could simply be replaced without signing. Of course, this would be for files that had originally an .apk/.odex pair because the ones which only had .apk in the first place, have classes.dex hashed inside the MANIFEST.MF and hacking these files would need a resign and would need to resign everything. So, that's why I think it's best to sign everything and just force the user hacking/theming to resign when he's done with it. It's simpler and everyone around this board (and the web) seem to use the same tools and signature to sign files, so it would be ok. Confusing? I know...
[Android] dsixda:
Here ya go, here's the fix for apps2sd. Damn, I was working with an HTC Hero 1.5 ROM at the time when I added this. LOL It no longer worked with newer ROMs.

Let me know if this works! Thanks for your valuable feedback.
[Android] dsixda:
I know, it's confusing.

And yes, I didn't sign anything in the framework or app folders.

Ok here's where I am confused --

If I decide to sign everything right now:

- For future theming of an APK, the user would NOT have to sign ANY APKs?

If I decide NOT to sign anything right now:

- For future theming of an APK, the user would have to sign that APK, and ALL the other APKs (for signature uniformity)?

Am I correct in this assumption? In that case, I agree with you in that we should do the signing in the kitchen, to make it easier.

Oh and another thing.. if the apks in system/app and system/framework get signed, we'd also have to sign the APKs under /data/app if it's enabled... right??

This signing thing may not be a good idea, in case the user decides to add APKs AFTER everything has been signed.
[Android] Yay 4 Juggs:
That is correct I had to manually sing all my modified apk's.
[Android] dsixda:
I think I'll leave the signing untouched then. Anyone who modifies an APK would likely know what or how to sign.

I could however provide a menu option to "sign all APKs in ROM", in these folders:

/system/framework

/system/app

/data/app
[Android] Yay 4 Juggs:
I think that might yield the best results...let those who modify apk's such as myself sign what we need to sign manually and let the kitchen do the rest...
[Android] dsixda:
But first, could someone with a Sense ROM please try out the attachment in post #1194 and try to deodex it that way? I want to make sure everything is confirmed this time ;)