Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support Wear 2.0 Apk uploads #217

Closed
danh32 opened this issue May 25, 2017 · 9 comments
Closed

Support Wear 2.0 Apk uploads #217

danh32 opened this issue May 25, 2017 · 9 comments
Labels
bug Indicates an unexpected problem or unintended behavior enhancement Indicates new feature requests
Milestone

Comments

@danh32
Copy link

danh32 commented May 25, 2017

We have a Wear 2.0 apk that we have to upload along with each regular phone apk release we do. I'm not sure the best way to support this case, as these apks are generated from different modules in our project. I've configured the plugin for each module, but what seems to happen is the second apk upload deactivates the previous one:

screen shot 2017-05-25 at 1 15 22 pm

So in my case, gradlew publishApkRelease runs wear:publishApkRelease first and successfully uploads version code 23612. Right after this, app:publishApkRelease runs and uploads version code 23611, deactivating the wear apk.

@saschpe
Copy link

saschpe commented Sep 15, 2017

Same here, would like to see a solution as well

@rocboronat
Copy link
Contributor

+1 here... A link for newcomers (like us): https://developer.android.com/training/wearables/apps/packaging.html

@EsteveAguilera
Copy link

+1!

@SUPERCILEX SUPERCILEX added the bug Indicates an unexpected problem or unintended behavior label May 24, 2018
@SUPERCILEX SUPERCILEX added this to the 2.0.0 milestone May 24, 2018
@SUPERCILEX SUPERCILEX added the enhancement Indicates new feature requests label Jun 8, 2018
@SUPERCILEX
Copy link
Collaborator

I see a few options here:

  • With the current plugin, you could create product flavors and split your app out into wear and app folders.
  • Once v2.0 comes out, there will be support for creating drafts that aren't published right away. The wear module could be in draft mode and the app module could finish up the publishing:
    play {
        // ...
        releaseStatus = "draft"
    }
    In the meantime, snapshot builds are available.

@ItsCalebJones
Copy link

@SUPERCILEX - can you give an example of how to configure this use case? In my case there is a :mobile and :wear module that both have bundles generated with bundleRelease.

@SUPERCILEX
Copy link
Collaborator

@ItsCalebJones To be completely honest, I have a very limited understanding of how Wear OS artifacts are built and published. If I recall correctly, the idea is follow this guide. You want to set the commit property to false for one of your artifacts and true for the other. That tells GPP to append artifacts to the current play store edit instead of wiping everything out and starting fresh. Please let me know how that goes!

@ItsCalebJones
Copy link

ItsCalebJones commented Nov 6, 2019

@SUPERCILEX - so here's how it works.

In one project directory I have multiple modules for simplicity i'll combine most into a :common library thats shared between both of the main app modules, then there is a :mobile module and a :wear module. When I go to create a release bundle/apk from the root of the project I usually simply run `./gradlew assembleBundle' this in essence runs both './gradle :mobile:assembleBundle' and './gradle :wear:assembleBundle'.

In each corresponding module/build/output there will be a mobile.aab and a wear.aab that I then sign and upload. For now i've found that I can do the following as suggested.

wear/build.gradle

play {
    serviceAccountCredentials = rootProject.file("publisher-key.json")
    track = "internal"
    releaseStatus = "completed"
    commit = false
}

mobile/build.gradle

play {
    serviceAccountCredentials = rootProject.file("publisher-key.json")
    track = "internal"
    releaseStatus = "completed"
    commit = true
}

And then invoke in order like this -> ./gradlew :wear:publishBundle :mobile:publishBundle --track=internal ... its not the cleanest to look at but it works.

Source: https://github.com/ItsCalebJones/SpaceLaunchNow-Android/tree/build/SLN-A_Play_Publisher

@SUPERCILEX
Copy link
Collaborator

@ItsCalebJones Yup, that's the idea. To ensure things work properly, you'll want this stuff in the root project build file:

gradle.projectsEvaluated {
    project(":mobile").tasks.matching { it.name.startsWith("publish") }.configureEach {
        mustRunAfter(project(":wear").tasks.matching { it.name.startsWith("publish") })
    }
}

Then you can just run ./gradlew publishBundle and it should work.

@hannesa2
Copy link
Contributor

hannesa2 commented Feb 12, 2023

Has someone a running example to publish a wear and a mobile apk together to play store ?
I publish with
./gradlew :wear:assembleRelease :app:assembleRelease :wear:publishApk :app:publishBundle -Dorg.gradle.project.track=alpha
I do this commit work:

image

image

image

Both are successful uploaded to PlayStore, but when I install and run app, nothing happens on wear. On wear nothing appears.
Here https://developer.android.com/training/wearables/packaging#distribution this never happens. Both are using same signing and versionCode differs.
Does someone has an idea what I'm missing ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Indicates an unexpected problem or unintended behavior enhancement Indicates new feature requests
Projects
None yet
Development

No branches or pull requests

7 participants