04-14-2011 01:20 AM
I'm trying (VERY UNSUCCESSFULLY) to sign my application so BlackBerry can approve it. I've noticed (now) that the bar file doesn't contain the 5 files its supposed to but also that I have an extra .bar.sig file of 0 bytes where my .bar file is. When I look at the xml file, I notice that the compiler is building a debug version as the <name> has -debug and the <id> has .debug appended to them. When I can get it loaded on the simulator, the screen name says -debug as well. I've tried EVERYTHING I can think of in Flash Builder to turn this off from doing clean builds, release for export builds, adding -debug=false to the compile line options... all to no avail.
I've got other problems with signing (too late did I notice that people were having too many problems with flash builder and now I have the dreaded:
"barsigner error: server error: Unable to register client 'XXXXXXXXXX' because there are no more registration attempts. If you have already registered with this server, then you must contact RIM to register additional users'
I'm really at a loss here with both of these errors. I ran into the later one yesterday and waited all day for a new csk key from RIM and now I suspect I'll have to get another one. I notice I can still register on the command line but FB seems locked up for signing and I can't use it anymore. I'm happy enough to do this via command line, but then can't figure out how to get a .bar without -debug info in it.
Thanks in advance!
Solved! Go to Solution.
04-14-2011 02:50 AM
if you are able to see the five files that are added after signing, that means your app is no longer in debug mode. its just an aesthetic issue where you need to just remove the debug mentions BEFORE packaging. im assuming you are taking the contents of your bin-debug and packaging them before signing via command line?
this method works but u just have to edit the -app.xml file and remove the mentions of debug in both the name and id tag fields.
what i do recommend though is first remove any .bar or .sig files from the folder you are exporting your production bar to then try exporting (after incrementing the version in the -app.xml file and then doing a project > clean) and this time instead of checking the box on the second dialog that says "Sign application" you are going to UNCHECK it and hit finish. this will create an UNSIGNED bar file in the directory you specified. now going to that directory (most likely if u didnt specifiy a directory, it will be ur root project folder) you will see ur bar file. avoid using anything from the bin-debug folder and that includes exporting to that folder.
at that point you can use the command line to sign the bar file using the last two steps (RDK and author) and you should be golden thereafter.
always remember that you can verify the bar file signature via this command:
blackberry-signer -verify -keystore cert.p12 -storepass mypass123 MyApp.bar
hope that helps. good luck!
04-14-2011 02:59 PM
Thanks JRab... I don't have the 5 files in my bar file. When I look at the .bar file (using winzip), it just has the swf file, my splashscreen, my icon and the -app.xml and blackberry-tablet.xml files (all in the air directory). I also have a META-INF directory with a MANIFEST.MF file in it. That file calls my application -debug as well. I'm guessing that's what is hanging up my ability to sign this. If I could figure out how to compile this beast (with files in different directories, lots of libraries and splashscreen/icon's), I'd bypass Burrito all together. I've done the signing things through the command line as you've said in many posts but my guess is that they fail because I'm not starting with a non-debug SWF/bar.
04-14-2011 04:26 PM
I think I've figured it out (or at least most of it). I took JRab's suggestion up there and went step by step ignoring those steps that generated errors and ended up with a bar file that passed the verification check above. I'm stil not absolutely its signed because it has only:
in the META-INF directory and just my swf, my assets and the two xml files in the AIR directory but since it passed the verification step, I submitted it anyway.
This signing is a fiasco.... surely there is a better way.
04-14-2011 04:29 PM - edited 04-14-2011 04:32 PM
You've done the second step, the one that ends in AUTHOR. You need to do the first step which ends in RDK, then AUTHOR.
Here are the two steps to sign:
<Double signing - first step>
blackberry-signer -verbose -cskpass <CSK PASSWORD FROM FIRST STEP> -keystore YOURCERT.p12 -storepass <YOUR STORE PASSWORD> <YOUR BAR FILE> RDK
<Double Signing - second Step>
blackberry-signer -keystore YOURCERT.p12 -storepass <YOUR STORE PASSWORD> <YOUR RIM-SIGNED BAR FILE> author
04-14-2011 07:32 PM
So much for -verify working! I figured as much even though it said it was just fine... I guess it verifies that one step worked but not the next. The RDK one was one of the ones that is failing. I'll list out everything I've done so we can get to the bottom of this once and for all... and then I'll document the solution so that everyone else suffering these problems with registration can have an easier time. It's been a long time since I've done any real development but this is ridicously complex - especially when developing on the device itself is so easy once you get the hang of flash.
I'll go get my third set of certificates and give it a shot from scratch without Burrito. Thanks.
04-14-2011 08:40 PM
04-14-2011 11:44 PM
OK, decided to start from scratch one more time... My app is called PilotView3D so I'll put out the commands here exactly as I'm typing them and stop at each step I have issues:
1) My "additional compiler arguments are set to: "-locale en_US -debug=false" in Project->Preferences->ActionScript Compiler
2) I turned off "Enable digital signing" on Project->Properties->ActionScript Build Packaging->BlackBerry Tablet OS
3) I deleted everything in my bin-release directory (where I've got Burrito putting the binaries).
4) I then edited the PilotView3D-app.xml file in my src directory so that :
<version>1.3.5</version> (from 1.3.4)
My other key tags are: (Burrito did these... I didn't touch them)
5) then I did a Project->Clean in Burrito. That put three files in my bin-release directory (plus my assets directory):
The same contents of the PilotView3D-app.xml file in the bin-release directory now have:
<id>PilotView3D.debug</id> (Burrito added the .debug)
<name>PilotView3D-debug</name> (Burrito added the -debug)
6) I deleted the .debug from the <id> and -debug from the <name> as per jrab above so it's back to the original and saved the file (same name, same location in bin-release)
7) then I did a Project->Export Release Build exporting to my bin-release folder. My Base release filename is PilotView3D V1.3.5. I select next and then leave Enable Digital Signing unchecked and press Finish.
I can see it working away and then it looks like it adds a tmp file, a bar file and then it deletes the WHOLE bin-release directory (this is new.... I've not seen this before). If I execute it again, I can see it create a bin-release directory (its not expanded in flash builder so I couldn't see the contents). I ran it again only this time I opened up an explorer window so that I could watch the contents of that bin-release directory. When it popped up the second dialog about the packaging settings, I notice that it's put the same files back in the bin-release directory as "clean" did... only this time the PilotView3D-app.xml file has the original names/id's in it... SO IT APPEARS CLEAN IGNORES THE -debug=false FLAG AND IT IS REDUNDANT TO EXPORT RELEASE BUILD. Now, I've still got the Packaging Settings Dialog open (from pushing next on the Export Release Build Dialog). I push Finish.... I can see it create a BARxxxxxxxx.tmp file and then it deletes everything in the bin-release directory (and would delete the bin-release directory if I wasn't inside it with the Windows Exploder).
7) Something is up there... so I try just doing a normal build (Run->Run As->Mobile Project)... now my bin-release directory has the right files in it... an assets directory with my splashscreen and icons, PilotView3D.swf, PilotView3D-app.xml and blackberry-tablet.xml. That stupid debug tag is back inside PilotView3D-app.xml again so I edit them out of the <id> and <name> tags again and save. LOOKS LIKE RUN/DEBUG/CLEAN ALL IGNORE THAT COMPILER FLAG.
8) Now that I have a bar file, I go to the trusty command line and navigate to the bin-release directory (with my path set to the SDK\bin of course). I type:
blackberry-signer -verbose -cskpass <mycskpwd> -keystore ..\AB_Cameron.p12 PilotView3D.bar RDK
It pops a prompt for "Enter Passphrase for keystore:" and I enter that and then it comes back with:
barsigner error: Certificate chain not found for: RDK. RDK must reference a valid KeyStore key entry containing a private key and corresponding public key certificate chain."
so... back to the certificates and step 1 of getting my certificates in order...
9) Initialize communication with the RIM signing authority by:
blackberry-signer -csksetup -cskpass <myCSKpwd> (I had to do a blackberry-signer -cskdelete first to start from scratch). I get a message that "CSK file created" which I assume is good news.
10) Try to register it with the RIM signing authority using:
blackberry-signer -register -csjpin <mypin> -cskpass <myCSKpwd> ..\client-RDK-XXXXXXXXXX.csj
It goes away for a while and then comes back with the famous:
"barsigner error: server error: Unable to register client 'XXXXXXXXXX' because there are no more registration attemps. If you have already registered with this server, then you must contact RIM to register additional users."
Knowing I'm already registered, I'm not going to sweat this one too much.
11) now I already have a Developer Certificate but to be safe, I'll create another one and call it something different. I type:
blackberry-keytool -genkeypair -keystore ..\AB_Cameron_Cert.p12 -storepass <myCertPwd> -dname "cn=AB Cameron" -alias author
The dname is the EXACT same as in my blackberry_tablet.xml and with what I registered my csj with. I don't get any warnings or responses that anything happened so I assume I'm still good.
12) I reversion it again (just in case), so I delete the bin-release directory, do a build-clean and then modify the resulting PilotView3D-app.xml <id> & <name> tags to remove the debug flags and then save. I have the assets, the swf and the two xml files in my bin-release directory. Everything looks normal.
13) Now on to sign the **bleep** bar file... first I package it according to the instructions:
blackberry-airpackager -package PilotView3D.bar PilotView3D-app.xml PilotView3D.swf blackberry-tablet.xml assets\eagle_f15e.png assets\PilotViewIcon.png
I get a few messages saying it's using the icon, "The bar manifest file is valid" and "Package created: PilotView3D.bar". All seems well so far.
14) Now to ask the RIM signing authority to sign my BAR file.
blackberry-signer -verbose -cskpass <myCSKpwd> -keystore ..\AB_Cameron_Cert.p12 -storepass <myCertPwd> PilotView3D.bar RDK
<myCSKpwd> is the password I typed in on step 9
<myCertPwd> is the password I typed in on step 10
And ARGH!!!! I get that **bleep** Certificate Chain error again. I'm totally stumped.
04-14-2011 11:56 PM
i was reading (and am still reading -- long post haha) but the part where you said the bin-release gets deleted -- try not to choose a directory to export to. just export to the blank text field and it will export to the root project directory. i ran into the same problem before.
i'll keep reading
04-15-2011 10:45 AM
Interesting... running Export Release Build without pointing at my bin-release directory still deleted my bin-release directory and contents for some reason (not even sure why it would know where that was now since I'm no longer pointing at it explicitly) but it left a .bar file in my root PilotView3D directory. I'm going to see if I can register that.