Thread
#compose-wear
    a

    Andrew Leung

    7 months ago
    I have a question related more so around distribution of an embedded wear app (not sure if this is the correct forum since this is more for jetpack compose), but the developer docs aren't very clear or up to date anymore. I’ll try here first and perhaps someone can direct me accordingly.
    I know in the past that it is possible to create a phone app with an embedded wear app so that when you install the phone app, you can get the companion wear app on your connected wear device. Is this flow still possible to do using APK distribution or since the switch over to AAB, the only way is via the Play Store approach?
    John Nichol

    John Nichol

    7 months ago
    @Kseniia Shumelchyk for a definitive answer but I believe the embedded app approach was deprecated a while back as we encourage folks to write apps to run and be installed standalone as devices are becoming more and more capable with wifi and LTE enabling them to run untethered
    a

    Andrew Leung

    7 months ago
    That’s kind of what I thought. And the docs clearly encourage it because they semi-mention and embeddable but don't really give definitive directions to that approach. I agree though it does make sense to make them all standalone. So if they are standalone, is it possible for the wear apps to be installed automatically for the user when they install the phone app? I think that's really what I’m trying to achieve.
    John Nichol

    John Nichol

    7 months ago
    Ah - well that is a different question - which again I will defer to others on - but what you do get is PlayStore->Apps installed on my phone - which helps with discovery
    Kseniia Shumelchyk

    Kseniia Shumelchyk

    7 months ago
    Hi there! Yes, we’ve moved to direction of having standalone watch apps which a recommended over fully dependent Wear OS apps. To the best of my knowledge auto-install isn’t supported at the moment . @Andrew Leung Did you check https://developer.android.com/training/wearables/overlays/independent-vs-dependent page?
    a

    Andrew Leung

    7 months ago
    Thank you for the references. Yes I’ve gone through those docs before, but I was always striving towards the old deprecated methods. I will move towards the standalone approach.
    Kseniia Shumelchyk

    Kseniia Shumelchyk

    7 months ago
    I’d even suggest to look into semi-standalone app which is the case for many apps we’ve seen so far. Paired phone can be useful to do authentication, or provide some optional, non-blocking functionality (e.g. having ‘open on phone’ button for user input).
    a

    Andrew Leung

    7 months ago
    what does “semi-standalone” mean from a distribution standpoint? My app currently shows a screen to tell them to open the app on their phone (to do exactly that, receive an authentication token) or order for it to function.
    I think by your definition, my app is definitely in the semi category since it does not include a native way to “login”
    Kseniia Shumelchyk

    Kseniia Shumelchyk

    7 months ago
    Sorry, I meant to say semi-independent - that’s that app that declare standalone in manifest, so phone isn’t required, but may be used for some (ideally optional) features
    a

    Andrew Leung

    7 months ago
    Does that mean in my Android Manifest I must mark it as
    <meta-data
            android:name="com.google.android.wearable.standalone"
                android:value="false" />
    as opposed to
    true
    ?
    We strictly only require the phone app for auth, once it receives a token, the wearable can function fully on its own.
    I’m sorry, I understand what you mean, the docs mention that semi means it is still in the
    true
    category.
    Kseniia Shumelchyk

    Kseniia Shumelchyk

    7 months ago
    this guide should help to make the decision which one to use: https://developer.android.com/training/wearables/packaging#specifying-app-as-standalone
    y

    Yingding Wang

    7 months ago
    I have a set semi-independent apps, with the standalone is “true”. You need to make two modules with the same package for playstore and both module containers “<application>” in AndroidManifest, and you will upload the both app.aab and wear.aab bundles to the same release, and playstore will recommend the right bundles to either handheld or wear device.https://developer.android.com/google/play/publishing/multiple-apks
    a

    Andrew Leung

    7 months ago
    With AAB’s being the only supported format going forward, how is Multi APK support still relevant since you can’t even upload APK’s anymore?
    y

    Yingding Wang

    7 months ago
    Yeah..wear os doc and guides are really out dated in a lot of areas, but the idea behind multi AAB is the same as Multi APK so far I understand. AAB helps to reduce your APK size. I switch from generate APK to AAB Bundle two years ago. But the workflow to update multi AAB in Playstore is the same as Multi APK used to be.
    For each module generated app (handheld and wear), you shall also use a different versionCode in your defaultConfig of your module’s build.gradle file.