The simplest is to register for new keys. In fact, when you look at the
online help for what to do with a lost password, they recommend just
One more thing. Those keys, are they app specific?
In the future If I create another app, will I have to get a new set of PBDT/RSK files ?
I haven't tested it thoroughly, but I don't believe the keys are app
specific. The keys and signing steps are linked to your company name, or
individual name, so you should be able to sign multiple apps. The thing
to remember is that the app id and version numbers need to be unique
across multiple apps.
So far I've just got one app submitted to App World, still waiting on
The whole signing/registering process is pretty long and confusing to me. This is what I understand (please let me know if I got it wrong)
1. Get signing keys from rim (two files)
2. Create Developer Certificate (.p12)
3. Register the signing keys with rim (two files)
4. Create debug tokens for specific playbook
5. Upload debug tokens to playbook
6. Once program is ready for appworld, sign it (Project - Export)
Now what happens if I want to up the version to 1.0.1, do I start at
4. Create debug tokens or 5. Upload debug tokens?
Oh it's a fun experience alright.
If you're using Flash Builder 4.6 then once you have the signing keys
you enter the info in the BlackBerry Tools registration wizard in FB
(This is dependent on installing the BlackBerry SDK for AIR first) -
Right-click the project folder > BlackBerry Tools > Configure Test
Devices... This will walk you through the entire process of setting up
your test device and getting the dev cert created etc. This is by far
the easiest process.
But if you like pain and suffering, then here's some ideas based on my
If you're doing the commandline approach, then there are two options,
one is the debug token route and the other is the signed app route.
Debug tokens allow you to setup the device for testing without having to
sign the app first. You associate the debug token with your device and
any app you build can load and run on that device (or number of devices
associated with the dev token).
Signing the app is easier for me on the commandline. This approach does
not use debug tokens but you do a few extra steps. The advantage here is
that once you've signed the app and tested it, it's ready to be uploaded
to the App World market.
Initial steps (regardless of which approach you take):
Steps done only once:
Download and install BlackBerry AIR SDK
1. Register for signing keys at RIM
1a. Register your compter with the .csj files and RIM signing servers.
2. Enable debug mode on PlayBook device (or simulator).
Steps done for each new app/version
3. Build the swf
4. Generate the -app.xml file - if new version, update version number,
if new app make sure its a unique app id
5. Generate the bar-descriptor.xml file (this can be named anything, as
long as it has the tags and required info).
Debug token approach:
Done only once for the device you're testing with, only need to repeat
if token expires
6. Create debug token
7. Package app with debug token and deploy to device
Signed app approach:
One time only
8. Generate .p12 signing file - use same company name associated with
9. Package the app
10. Sign the application (2 step process):
10a. Sign with RIM
10b. Sign with Author
11. Deploy to device.
So, long answer to your short question, you don't regenerate the debug
token for each new app/version. If you go through the signing process,
then you do steps 9-11 each time. Make sure to increment the version
number to sign the app again.
As you can see, it's a lot easier if you use FB 4.6 with the BlackBerry
tools that install with the BB AIR SDK.
Thanks for a great explanation iBrent.
I'll try that once I get the new keys.