Obb file for two APKs with different versionCodes not supported

[stephan-nordnes-eriksen]

First of all, this is a really great tool! Thanks for making and maintaining it!

I am trying to upload 2 APKs, one for armv7 and one for arm64. As per the android documentation, the versionCode for the arm64 is one more than for the armv7 (eg. armv7=10, arm64=11). I have an expansion file for each of them, which in theory could be the same, but they are two different in my case.

Either way, I have looked through the code, and it seems as though only the first apk file (based on versionCode) will receive the obb file. This is unfortunate as I would like to use apkup to serve both the 64bit audience, and the older 32bit users.

My code for reference.

   const apks = [
        `./artifacts/${config.projectName}-arm64.apk`,
        `./artifacts/${config.projectName}-armv7.apk`
    ]
    const obbs = [
        `./artifacts/main.${config.buildNumber + 1}.${config.androidPackageName}.obb`,
        `./artifacts/main.${config.buildNumber}.${config.androidPackageName}.obb`
    ]
    apkup
        .upload(apks, {
            obbs,
            releaseNotes: [
                {
                    language: 'en-US',
                    text: myUpdateText
                }
            ],
            track: 'internal'
        })
        .then(data => {
            console.log(` > ${data.packageName} version ${data.versionCode} is up!`);
        });

Not sure how easy or hard it would be, but perhaps it would be possible to create an apkObject of some sorts that has a list of related obb files inside it, which in my case might perhaps look something like this:

apkup.upload([
    {
        apkPath:  ./artifacts/${config.projectName}-arm64.apk`,
        obbs: [`./artifacts/main.${config.buildNumber + 1}.${config.androidPackageName}.obb`]
    },{
        apkPath: `./artifacts/${config.projectName}-armv7.apk`,
        obbs: [`./artifacts/main.${config.buildNumber}.${config.androidPackageName}.obb`]
    }], 
    {
        releaseNotes: [
                {
                    language: 'en-US',
                    text: myUpdateText
                }
        ],
        track: 'internal'
    })

From an implementation point of view the configs above could be added without breaking existing interfaces by doing something like the below (typescript syntax)

export interface apkSpecificationObject {
    apkPath: string,
    obbs?: string[]
}
function upload(apk: string | string[] | apkSpecificationObject | apkSpecificationObject[]) {
    let apkArray: (string | apkSpecificationObject)[] = []
    if(Array.isArray(apk)){
        apkArray = apk
    } else {
        apkArray = [apk]
    }
    apkArray = apkArray.map(apkInTransit => {
        if(typeof apkInTransit === 'string') {
            return {
                apkPath: apkInTransit
            } 
        } else {
            return apkInTransit
        }
    })
    // ... do whatever we need to do with the list of apkSpecificationObjects from this point on
}

[stephan-nordnes-eriksen]

(Sorry in advance if there is a double post of this issue as github is throwing 500 errors my way today)

[nprail]

@stephan-nordnes-eriksen Thanks for the suggestion! This is definitely a use-case I hadn't thought of.

I like the idea of an APK object with the path to the apk and obb files. The only hard part would be translating that to the CLI.

As a workaround, can you do the upload twice, once for each architecture? Or is there something that makes that not work? I've never used obb files before so I'm a bit unfamiliar with how they work.

Something like this:

const config = {
  releaseNotes: [
    {
      language: 'en-US',
      text: myUpdateText
    }
  ],
  track: 'internal'
}

apkup
  .upload([`./artifacts/${config.projectName}-arm64.apk`], {
    obbs: [`./artifacts/main.${config.buildNumber + 1}.${config.androidPackageName}.obb`],
    ...config
  })
  .then(data => {
    console.log(` > ${data.packageName} version ${data.versionCode} is up!`)
  })

apkup
  .upload([`./artifacts/${config.projectName}-armv7.apk`], {
    obbs: [`./artifacts/main.${config.buildNumber}.${config.androidPackageName}.obb`],
    ...config
  })
  .then(data => {
    console.log(` > ${data.packageName} version ${data.versionCode} is up!`)
  })

[stephan-nordnes-eriksen]

Wouldn't that create two new, whats the name, "bundles" or something? I think that would essentially result in two distinct versions on the play store, one overriding the other. I havent tried yet so I can't say for sure. I will test it out at the first opportunity.

I totally see the cli-problem. Would it be inconcievable to use json in the command line as well? Sorry for my ignorance if this is not possible for some obvious reason, but in my mind it could look something like this:

$ apkup .... --apk-objects="[{apkPath: '...', obbs: ['...'] }, {apkPath: '...', obbs: ['...']}, ....]"

[nprail]

@stephan-nordnes-eriksen Yep, you are right. That would create two separate releases.

JSON as a CLI param is technically possible. Just not a very fun developer experience 😄

I'm pretty busy for the next week so if this is urgent for you, feel free to implement it in a backward-compatible way without the CLI part (sounds like you have a pretty good understanding of what needs to change). Otherwise, I'll get to it hopefully sometime in the next few weeks.

[stephan-nordnes-eriksen]

@nprail Have you had the opportunity to look into this? I might have a go at this at some point soon, but my schedule has been quite busy as well.

[nprail]

No, unfortunately, I haven't had much time... 2020 has been crazy, to say the least. I'll try to take some time to work on it either this Saturday or sometime in the evenings this week. But if you are willing to take a go at it as well, that would work.

I did come up with a hopefully good way to do the CLI, though. In each --apk, you could add a comma separated list of OBBs after the APK. Something like this:

apkup ... --apk="path/to/your.apk,path/to/your/1st.obb,path/to/your/2nd.obb"

[stephan-nordnes-eriksen]

Crazy indeed.

A comma seprated list seems like a really good solution in my mind. I would love to help out if I can. I will chime in on #38, possibly getting some time in for coding!

[nprail]

I'm going to leave this issue open until the first beta of v2 is released.