Roku Developer Program

[kevintwister]

We just received this back from our tester on a channel that we've had up for over 2 years. We were just fixing a bug we had with some video playback. This is blocking us from fixing that bug and I have no clue what that means. I emailed our tester however have not heard back yet. I figured I would ask here also so that we can expedite things. Anyone understand "Channel under test doesn't share linking info with channel from channel store"? Thanks!

[squirreltown]

"kevintwister" wrote:
Anyone understand "Channel under test doesn't share linking info with channel from channel store"? 

It could mean many things. Maybe the wrong dev id is being used to pkg and users saved/store info is not being found.

[kevintwister]

"squirreltown" wrote:

"kevintwister" wrote:
Anyone understand "Channel under test doesn't share linking info with channel from channel store"? 

It could mean many things. Maybe the wrong dev id is being used to pkg and users saved/store info is not being found.

Maybe my lead developer and myself are not understanding, however the "dev id" changes depending on the device that is being used to create the package. We have several Rokus here that we use to create packages and each one has it's own "dev id". We have released several versions before from different Rokus that we have here in the office and never had a issue. 

[belltown]

When you update a published channel, the package you upload should use the same developer id as when the channel was originally published. Registry entries, which may include sign-in information, etc., are associated with the developer id, so if you submit a package with a different developer id, the channel no longer has access to its previous registry data, and it will appear to the user as if they are installing the channel for the first time.

[Veeta]

You need to keep the same developer id+password for the duration of a single channel.  The dev id is tied to a number of things, but most obviously the registry entries on the users devices.  If you change the developer id, you won't be able to read registry entries you had previously written (e.g. authentication info).  It may be that previous versions of your channel got through with different dev ids but this is not how most channels are managed.

You need to persist 3 things when you provision a new channel:
1) Developer ID from running 'genkey'
2) Password from running 'genkey'
3) Any signed package from the device with the above developer id

This way you'll always be able to "rekey" a roku device to allow it to sign new packages with the same developer id as your original package.

[jmss82]

"Veeta" wrote:
You need to keep the same developer id+password for the duration of a single channel.  The dev id is tied to a number of things, but most obviously the registry entries on the users devices.  If you change the developer id, you won't be able to read registry entries you had previously written (e.g. authentication info).  It may be that previous versions of your channel got through with different dev ids but this is not how most channels are managed.

You need to persist 3 things when you provision a new channel:
1) Developer ID from running 'genkey'
2) Password from running 'genkey'
3) Any signed package from the device with the above developer id

This way you'll always be able to "rekey" a roku device to allow it to sign new packages with the same developer id as your original package.

I have lost the dev key and password credentials and tried to recover them by doing a rekey without success, what steps should I follow to be able to perform an update to a channel already published.

[belltown]

You can copy the key from a package that was previously created with the desired key, by following the instructions in the documentation here: https://sdkdocs.roku.com/display/sdkdoc/Packaging+Your+Application#PackagingYourApplication-Rekeyin...

If you don't have a package created with the previous key, then you're screwed.

[RokuMarkn]

jmss82 says they lost the password, so they can't do a rekey. In that case, their only option is to publish the channel with a new key. This means that all users will lose any data stored in the registry. How serious that is depends on how the channel is written. It could mean no problem at all (if the channel doesn't use the registry), or it could be a big problem for their users (if valuable nonreplaceable data is stored in the registry).

--Mark

[kevintwister]

"RokuMarkn" wrote:
jmss82 says they lost the password, so they can't do a rekey.  In that case, their only option is to publish the channel with a new key.  This means that all users will lose any data stored in the registry.  How serious that is depends on how the channel is written.  It could mean no problem at all (if the channel doesn't use the registry), or it could be a big problem for their users (if valuable nonreplaceable data is stored in the registry).

--Mark

Thanks Mark. We don't store much of anything in the registry. I think it's only used to pre-populate the last search made. The rest such as saved favorites, account options, preferences, etc are all stored in our database. Our users must have a registered account to save all of that data. 
The odd thing is my lead developer (jmss82) has been using different devices for 2 years to create packets which he is telling me has always generated a new key depending on the device. We have submitted several updates in those 2 years. Your QC guys have never noticed or mentioned it before and it's why we got confused with this last submission. 

We'll just go with the last key submitted and make sure we keep using that key in the future. In the meantime we need to figure out how to get the rekey to work on the different devices. He is still getting errors on that. 
Thanks for all of the replies.

[EnTerr]

"kevintwister" wrote:
The odd thing is my lead developer (jmss82) has been using different devices for 2 years to create packets which he is telling me has always generated a new key depending on the device. We have submitted several updates in those 2 years. Your QC guys have never noticed or mentioned it before and it's why we got confused with this last submission. 

Recently they published new certification requirements list, seems they changed what they check and what not - and checking that the new version is signed with the same key as previous one sounds like a good thing to check for and warn before approving. I imagine this is more of a "warning" than a "fatal error"