Thanks for the feedback — I don't use expansion files myself, so I'm always interested to hear how people use them in practice.

But if I am uploading a new main.obb, the existing patch.obb is not desired.

So in this case, if you provide a new main OBB to be uploaded, but no patch OBB, then the plugin shouldn't try to associate an older, existing patch file with the new APK? Would that solve the problem?

Why not allow us to explicitly list which obb versions we are using. All the information is present to determine whether the obb must be uploaded or is already uploaded.

I don't quite understand this — how would you like to explicitly list the OBB "versions" to be used? What's an OBB version (an APK versionCode that has an OBB file associated?)? What do you mean by "all the information is present"?
(You'd be surprised at how little useful data the Google Play API actually returns).

Rather than the "Re-use expansion files" checkbox, do you want to have something like a couple of textfields (for "main" and "patch"), where you explicitly type in the older APK versionCode whose OBB file should be re-used?
If that's the case, wouldn't that require re-configuring your job for most releases involving an OBB update?

Sorry if I'm missing something obvious, but if you could describe a scenario in more detail (e.g. which APKs with which versionCodes are being uploaded, along with which OBB files are being uploaded or associated, and what the desired result is), and if you could describe what the plugin UI should ideally look like to cover your scenario, that would be a great help.

This would also be helpful for applications that have multiple apk's since they may also have different obb files associated with different apk's, so the previous main/patch obb may not be the correct "old" obb to use.

Yeah, I guess this is the scenario I mention on the wiki under "feedback wanted".

I don't know what's the best way to solve this; I did vaguely think of requiring mapping files for main and for patch, which maps the new APK versionCode to an older APK versionCode, from which the OBB should be re-used.

So in this case, if you provide a new main OBB to be uploaded, but no patch OBB, then the plugin shouldn't try to associate an older, existing patch file with the new APK? Would that solve the problem?

Yeah that's right. The patch will normally (at least for me) over-write the main obb where they differ, so an old patch file is kind of bad. When you put out a new main you are essentially declaring a new baseline.

So not associating older patch obb's would indeed solve the issue for me, at least in this instance. But there might be other cases where you simply want explicit control over which obb's to use.

I don't quite understand this — how would you like to explicitly list the OBB "versions" to be used? What's an OBB version (an APK versionCode that has an OBB file associated?)? What do you mean by "all the information is present"?

Yeah, the obb version refers to the apk version code. So if you are uploading apk version 10 and you specify main.10.com.foo.bar.obb and patch.7.com.foo.bar.obb then you know the main obb is being uploaded and the patch is from apk version 7. You could also, as you suggested in your comment, just supply the version number you want to associate in both cases (of course, you still have to find the obb files that you are uploading – perhaps by just supplying a directory to search).

If that's the case, wouldn't that require re-configuring your job for most releases involving an OBB update?

The obb names are determined in a previous step (need them for building the apk since the app needs to know what files to expect – blame google) so they get passed in as parameters already. The only reason i have to do configuration change between runs now is that the toggle box can't be changed via a parameter.

I don't know what's the best way to solve this; I did vaguely think of requiring mapping files for main and for patch, which maps the new APK versionCode to an older APK versionCode, from which the OBB should be re-used.

I think it's enough to put this on to the user of the plugin. If they can explicitly list what main and patch obb versions to use, then they can handle the multi-apk case however they want. They could embed information in the version number, use a mapping file, or query the google play api on their own – whatever works for them.

Sorry if I'm missing something obvious, but if you could describe a scenario in more detail...

Could go a lot of ways, but how about something like this:

Two text fields, one for main and one for patch, and an upload directory. You enter whatever version number you want to use for each obb (possibly none). If the version number matches the apk version that is being uploaded, then the plugin tries to upload the properly named obb from the upload directory (properly named as in main.ver#.com.foo.bar.obb). If the version number does not match the apk version, it is assumed to be a previously uploaded file. Obviously, that needs to be verified, but pretty sure the google play api gives you that.

The key to all that is that the plugin user can use parameter to specify that, so there's no configuration change needed each run.

Of course, this could be considered advanced usage. Being able to specify the way you do right now is actually pretty convenient (at least when you only have one apk, which is currently my case) but would be better if you could specify not uploading a patch when uploading a main (pretty sure you only ever upload one or the other, but others may do it differently).

Hope that all makes sense. Hard to tell how much I typed in this little text box.