I have a question related more so around distribut...
# compose-wear
a
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?
j
@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
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.
j
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
k
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
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.
👍 1
k
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
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”
k
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
Does that mean in my Android Manifest I must mark it as
Copy code
<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.
k
this guide should help to make the decision which one to use: https://developer.android.com/training/wearables/packaging#specifying-app-as-standalone
👍 1
y
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
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
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.