Repackaging project with different bundle identifier Android

Development Pipeline & Plugins
, ,
1

Hey folks

We’re trying to create 2 AABs for our project, each with a different bundle identifier and code signing identity, I thought that I’d be able to run package & archive with BuildCookRun after a previous successful build, but that isn’t working for me

I don’t want to run a full build & cook because I want to use the same compiled game project, and the same assets (identical, binary same) as I want both packages to be able to use content from the same CDN upload, as I understand (correct me if I’m wrong) content cooking is not yet deterministic, so if we were to re-run the cook step we may end up with different outputs (To be honest, even if it were deterministic I’d prefer to not pay the cost of cooking again and run the risk of the content being wrong)

The way I’m trying to do this is to first run a BuildCookRun with -build -cook -pak -package -archive, and then run another BuildCookRun with only -package -archive

When I run BuildCookRun the second time, it runs a stage command which finds no manifests and immediately fail with a null reference exception inside RunIoStore

I’ve attached a log of the second run which fails immediately

The command line arguments passed here are the same as the first build, except the first build of course runs with -build -cook -pak, and without the ini overrides at the end.

Is repackaging like this a supported workflow? Any advice on how I can get this working?

UAT_REPACKAGE_FAIL.txt(7.73 KB)

2

Hello!

You should be able to get it to work by adding the -stage argument. This will result in the creation of the missing manifests. The new package will use the same already compiled exe and cooked data.

Regarding the determinism of the cooked data, the engine classes are mostly deterministic at this point. The engine team is resolving any cases were it is not. The place were we cannot guarantee determinism is in the classes defined at the project level. The source of non-determinism are diverse and can stem from the code or the data itself. Make sure that you properly initialize your classes. Padding\alignment gaps in classes can be source of determinism so it can sometimes require extra code to zero those parts of the classes. You can use the -diffonly argument on a subsequent cook to have the engine compare the data and report on the classes that don’t result in identical data.

Regards,

Martin

3

Thanks Martin

I’ve got this working now without re-cooking :+1:

In addition to adding the -stage argument, I had to explicitly add the -skipcook argument