devs_mobile_apps-archived

[bronze nebula]

no, i actually left it empty, because as far as i understood that, it wraps another zone around that zone then, right? so for me: empty value

i haven't seen any events in this regard, gotta check that probably. but it seems like it stops updating positions for some reason. Could potentially also be related to android 13 beta as i own a Pixel 6 Pro

[atomic helm]

yup exactly, now the question is if android detected the zone event

the bets way to troubleshoot location issue is to by the logs, we actually print the entire decision making process when it comes to location

youll see when things are registered, events being received etc..

so you can see if it was registered for the zone, or if an event was ignored etc...

[bronze nebula]

okay, where to see it most accurately? i tend to look up the logbook for those things..

[atomic helm]

Configuration > Companion App > Show and Share Logs

[bronze nebula]

ah perfect, thanks

[atomic helm]

or you can use Logcat from android studio 🙂

[bronze nebula]

weeell.. not using android studio while driving though 😛

[atomic helm]

hahah yea

the logs from teh app go by the PID so if the app was killed it wouldnt retain long term logs

for that, its recommended to use an app liek Logcat Reader to look at logs not caught by our logger

personally i also keep logcat reader on my phone so its easier ot troubleshoot things like that

[bronze nebula]

yep, thought so. 😄

[atomic helm]

for your test scenario you may want to consider setitng up an automation that listens for the zone entering event so you can see if the app reacts at the same time

https://companion.home-assistant.io/docs/integrations/app-events

location fixes/bugs are the fun ones to test since it may involve leaving and driving aroudn 😛

android studio does offer spoofing of location too, but i foudn it sorta finicky during testing but it did the job for triggering zone events

[bronze nebula]

yep. in earlier days on other topics a used to use lockito, which also spoofed locations (not for pokemon go though, used to work for a sports company with a running app)

[calm maple]

After fixing a bug the maximum number of entities the app provides is 79 now, only 21 to go 😄

[velvet trail]

Suggestion/Idea: Why can't I just select a sensor to use with a complication?

Right now, I'm required to write a template

[green aurora]

"Easy complication entity ids - just enable which should show up" is my todo list entry around that.

likely as part of an overhaul allowing synced complication settings.

[velvet trail]

Alright, in that case, nothing said 👍 😄

[elder haven]

i have noticed the app is stretched on my tablet (Samsung Galaxy Tab S8 Ultra), i don't think the resolution its supported yet

https://i.imgur.com/x1qdZ2E.jpeg

[atomic helm]

do you see the same issue in chrome for android on the same device? also this channel is not for support

i dont really see anything wrong with the screenshot

[elder haven]

my post wasn't a support question, it was a suggestion for a fix, because i think it's just the app that needs a little update.

if you look lower left on the blue icon, it's an oval

https://i.imgur.com/CzOkAQh.jpeg

this is it loaded in the chrome browser

[atomic helm]

it would still be a #frontend-archived issue but this channel is not for suggestions or fixes...its specifically to talk about developing features

[elder haven]

seemed more like a mobile version issue to me, but fair enough

[atomic helm]

the app doenst control the display like that, we simply load the page and the HA frontend handles how it is rendered

[elder haven]

my thought was an android WebView issue or app resolution issue

[atomic helm]

you can try checking that Android System Webview is up to date but that would be about it...the HA frontned would need to account for the device and screen size

[elder haven]

my device fully up to date

[green aurora]

figured out how to make HLS streaming work using an untrusted certificate by looking at the private API that WebKit does to make it work 😭

[errant brook]

This request is very similar to what I was talking about when wanting to have Home Assistant on my daughter's watch. I'm OK not having the full featured template complications there, but selecting which entities to toggle or display as a complication can be done in app without the iPhone companion.

[green aurora]

yeah that seems doable

the hard part will still be onboarding and such

[green aurora]

the next one

[green aurora]

…client certificates are awful on ios, lol. gotta make a keychain entry and pull it out to then use it. and -- best i can tell -- some configs don't even ask or hint that they need a client cert. like caddy just throws an ssl error if it wants a certificate rather than asking for a certificate.

[green aurora]

ah no it doesn't, i just couldn't read the awful documentation, hooray, i think

[green aurora]

yep, works like a charm otherwise. only major requirement is the certificates need to be p12, but otherwise threads through in exactly the same places as the cert trusting code. dope.

gotta write my own login webview thing now, the system one can't do client certs

[green aurora]

…oof, background url sessions do not support client certificates. may be a dealbreaker - watch effectively requires it, and widget definitely will.

[fallen crown]

App rejected again because of wear....

Issue details

We found an issue in the following area(s):

SPLIT_BUNDLE 2165
Additional notes related to this issue:
For example, your application crashed while scrolling

[atomic helm]

i wish there was a support section on SPLIT_BUNDLE 2165

[calm maple]

Do any of the automated tests in the pre-launch report show a crash?

The example is almost too specific to be an example

[calm maple]

Pretty sure 2165 is the version code, and split bundle refers to the fact that it's not the full bundle (= main + wear)

[atomic helm]

is it me or is version 2165 the last published release?

the latest beta on github is 2300 IIRC

[calm maple]

The latest beta published to the Play Store is 2300, isn't it? That's the beta version I've been seeing in issues for a few weeks now

[atomic helm]

yea 2300 is what my wifes phone is on and she only sticks to beta updates on google play

just tried to load latest master on my wear os device but no issues with scrolling here

[atomic helm]

would this be from the play store console?

[calm maple]

Yes, Google does some automated checks including running the app on an emulator and generates a pre-launch report you can see in the console. For example: https://support.google.com/googleplay/android-developer/answer/9842757

[fallen crown]

Pre Launch report doesn't have any crashes

[dire bough]

How does the automated testing work for Google without having a home assistant instance?

[calm maple]

#android-archived message

Or maybe they found something in the login screen

[fallen crown]

Part of me wants to disable on device login, for everyone to use the companion app to login

[dire bough]

Main downside is for people that use their wear device with an iphone. But no idea how many of those we have...

[calm maple]

That would mean the app is no longer standalone 😦 Although I do think we should push the phone sign in more, right now it is literally the last option and you'll only find it if you scroll down

Also doesn't change the fact that Google is preventing new beta releases for an 'issue' with the stable release

[atomic helm]

yea and the last beta 2300 i dont see anything glaring that would cause it to crash

presumably the issue is from beta 2300 and to the next week where we cut the next weekly beta

[fallen crown]

I tried to upgrade the server they use to validate since it was 1.5 years out of date..... But it never came back up

So we can't really push a new build right now anyway until that comes back

[fallen crown]

It's true..... but right now it's a total hack how we login on device.

[fallen crown]

I read about oauth logins that let you stay standalone but let you log in through device, but I'm not sure home assistance off would work. Never had time to investigate.

[dire bough]

This is very true haha. Couldn't find an official way to login other than through a webpage back then, don't know if anything has changed

[calm maple]

That sounds nice but HA auth seems very nonstandard

[fallen crown]

It hasn't I don't believe

What I would love to see is an auth method that has you enter the 4 digit type thing

Don't know what that's called

Would be really useful for wear and TV

[calm maple]

If it was 1.5 years out of date maybe the app would've crashed, especially Wear isn't very backwards compatible

[dire bough]

That would be awesome indeed!

[fallen crown]

Plex does it

When logging into TVs

[calm maple]

But doesn't that require a specific UI in Home Assistant?

[dire bough]

By the way, separate question. I'm working on complications support for the wear app. For the config view I want to make an entity selector, which means I need to duplicate some code from both MainViewHolder and HomePresenter. Any smart ideas other than simply duplicating the code into a new holder and presenter? Can I make a parent class? Offload functionality to a common component?

[dire bough]

Yeah and large backend changes I can imagine

[fallen crown]

Might be able to do it with only a backend change

API call -> triggers a notification from core that lets you enter the numbers?

[fallen crown]

Not sure why the constructor injection wasn't working in the SensorSettingsViewModel but here is a workaround for now.
https://github.com/home-assistant/android/pull/2566

[dire bough]

I don't have much experience with the websocket yet, but when I add a complication to the watch face I want to start listening to state changes of the associated entity (only with the screen on I guess?). Can someone point me in the right direction to listen to these state changes?

Also it seems that we currently listen to all state changes, does it make sense to listen to only changes to specific entities? Or did I just not look hard enough for that implementation?

[calm maple]

Listening only for specific state changes was introduced in core *2022.4 and is not yet supported by the app

[dire bough]

Ah right, then I'll listen to all for now

[calm maple]

To improve efficiency you should probably try to reuse the entity state you receive

See the entity state widget for an example

Conceptually also quite similar to a complication

[dire bough]

Thanks! I'll have a look at that one 🙂

[dire bough]

This is exactly what I need! So I'll play with it tomorrow

[green aurora]

which websocket api change allows watching only certain states? i think i missed that one

[fallen crown]

https://developers.home-assistant.io/docs/api/websocket/#subscribe-to-trigger

[green aurora]

nice thanks

[fallen crown]

Found the actual issue with the sensor dao, missing @AndroidEntryPoints took my two braincells far to long to figure it out. PR coming soon

[fallen crown]

https://github.com/home-assistant/android/pull/2575

[bronze nebula]

@fallen crown i found an issue when opening the bluetooth device selection in location settings.. might your fix be related to that?
Btw: who is actually receiving crashlogs of the android app? I might have spammed some today 😅

[calm maple]

The Android prompt asking you to send a log when the app has crashed is sent to the Play Store console, unless you go there to look at them no one will see it 🙂

I'm also getting a crash when opening the Bluetooth device option in location settings but it's not related to recent changes, please open an issue on GitHub with the stacktrace (I'm getting java.lang.IllegalArgumentException: Key Steel HR FD was already used. If you are using LazyColumn/Row please make sure you provide a unique key for each item.)

[bronze nebula]

No i meant the ones that are automatically sent with the option in the settings being turned on. Not the defaulz android ones

[atomic helm]

oh looks like setting fields are not correct

the toggle is back to text

[bronze nebula]

I haven't had the time yet to check the logs, thanks for the input..

[calm maple]

Not seeing that on a fresh install...

[atomic helm]

weird thing is i only see it on the high accuracy mode toggle

the rest seem to be fine

I see the same exact error on bluetooth device selection too

[calm maple]

Easy to reproduce usually means easy to fix 🙂

[atomic helm]

filed it here https://github.com/home-assistant/android/issues/2579

i think we had a PR similar to this error where we added keys to our lists?

and yea i dont see the toggle issue on a new install either, i imagine since that bug we had mine never changed....oh well next time i need to start fresh itll clear out

[bronze nebula]

I actually faced the crash on fresh install. Maybe it is really just related to the device names as keys as mentioned in the bug.

Guys, you are awesome and thanks for taking care of that quicker than anything else. 👍 👍

[fallen crown]

Just sent the play store app for review again. Hopefully with an updated demo server we can get through. Otherwise I'll need to dispute which might take even longer.....

[green aurora]

@deft jewel i think you can kill privatedemo.* -- we've got private-demo.* now in the HA AWS i believe

[atomic helm]

still battling with google play reviews, submitted a PR to update the screenshots as we got another rejection

My latest PR reflects changes based on the one comment we got back For example, your application does not provide user interface as shown/described on the store listing.

[fallen crown]

Another review requested with the latest changes.

[atomic helm]

https://tenor.com/view/please-please-god-praying-pray-for-me-pokimane-gif-14474281

[dire bough]

Any news on the Google play review?

[atomic helm]

apparently our production build is broken and crashing for the reviewer so they cant review the beta as a result

[calm maple]

Were you able to reproduce it or did you get a stacktrace to fix it?

[atomic helm]

i havent been able to reproduce it myself and have also used the private demo site we supplied to make sure there are no issues....not sure if they sent a stacktrace but it sounds like they want us to push a new prod build

right now im just the messenger 😄

[green aurora]

getting the device name now requires getting an entitlement for it

[green aurora]

bah, my ipad isn't new enough to do the new window mode

[fallen crown]

@atomic helm Just need you to address https://github.com/home-assistant/android/pull/2584/files then I say we go for prod release and get Google happy again. Any objections or other PRs we think we need before we do @calm maple?

[calm maple]

I haven't had time to test more PRs this week, but the app seems to be stable

So I'd say go for it

Although maybe the in-app changelog should also be updated?

[atomic helm]

yea if were gonna push to prod lets update the changelog too

[fallen crown]

Ok, you mind handling it @atomic helm? You are much better with words than me, haha

[atomic helm]

yup getting it done right now 🙂

[fallen crown]

Ty!

[atomic helm]

ok submitted

[fallen crown]

Once that's build and merged I'll cut the release

[atomic helm]

🤞

[fallen crown]

And manually requested review in play store.... now we wait.....

[atomic helm]

they seem to take a day to respond so hpefully well just see the published build later tomorrow 🙂

[calm maple]

Also let's hope the app isn't due for another extensive review any time soon after this

[fallen crown]

I wish I knew what triggers them

[atomic helm]

seems to be random, i remember at first we thought it was anytime the manifest changed

I think because we have a wear OS app it probably triggers it more though

[fallen crown]

Normally we get our rejection by now so hopefully we are in process, fingers crossed

[fallen crown]

It's a miracle!!!

[atomic helm]

https://tenor.com/view/its-done-frodo-lord-of-the-rings-elijah-wood-gif-8259334

ill go drop a note in #android-archived about not having a proper beta cycle so folks know to submit issues

[calm maple]

Does this also mean the Wear OS app is now available in the stable channel / without enrolling in the beta?

(The companion website still mentions you have to be a beta user, and I don't have a Wear device to test)

[atomic helm]

technicaly its been in release, I think we need to remove that text lol

[atomic helm]

looking at sentry no new issues that have a wide impact in the new release

[fallen crown]

I really need to find time to either filter the junk or fix the existing issues.....

[twin summit]

Thanks for the super speedy code review! That was such a pain-free experience, maybe I should submit patches more often 😅

[icy cedar]

Is there any plans to make it so you can have multiple Homeassistants in the same App?

[atomic helm]

there is an existing feature request, but no set date or anything

[calm maple]

^ assumes you're talking about Android, if you're using iOS see https://companion.home-assistant.io/docs/getting_started#adding-additional-servers

[atomic helm]

Dear developer

[calm maple]

I'm working on showing the entity state in the chips on Wear and for some reason the default linear gradient when using two stops at the same position is also diagonal?

I should probably try to get a vertical line but it is growing on me

[dire bough]

I honestly dig the diagonal line 😁

[calm maple]

It has been fixed while working on RTL support but you can always add a comment requesting it when I open the PR 🙂

RTL is very confusing for someone who is not used to it, bars filling up from the right 🤯

[atomic helm]

yea RTL is fun lol, we deal with it a lot at work lol

the emoji and text arrangement throw me off there lol

[dire bough]

BTW @calm maple I hope to have a MR ready tomorrow to bump compose for wear to the latest beta. I believe there is a change in the default backgrounds of toggle chips, so don't know if that would impact what you're currently working on?

And why is the placement RTL but the text still LTR in that screenshot? 😅

[atomic helm]

check that rotary input still works lol....last I checked on the latest update we needed to make additional changes so I stopped lol

on a side note, my FR at google is now in progress 🙂 so I assume next iteration it should support it natively

[dire bough]

Yeah that is one of the last things I still need to check, I think they added more official support right?

[calm maple]

I think it only has a major change for the SplitToggleChip, which we don't use, but I'll have a look tomorrow and test the changes for the latest Compose locally

[atomic helm]

yea thats what it looked like, I try to follow the People in Space example that they linked me to but kinda hard to follow after their recent changes

[calm maple]

This is Android's forced RTL support for any language, I believe it only changes text order when there is a space or line break and not in words to keep it somewhat readable

As @atomic helm mentioned, you can see that the emoji which is part of the name is placed to the left in the RTL screenshot

[dire bough]

Okay, I will have a look at it. Think it might take some trial and error

[dire bough]

Right! Makes sense haha

[calm maple]

Looks like the newest version is actually rc01, beta03 is already outdated

[dire bough]

Ah yes, I knew there would be a new version this week, but expected it to be another beta

[atomic helm]

i wonder if the performance is better now, I think they mentioned they would focus on performance improvements in the beta cycle

[calm maple]

It might also be related to the app

[atomic helm]

hopefully by performance they mean load times and scroll lag lol

[calm maple]

While working on the state background I noticed a lot of recomposition, even if the specific entity didn't change (because I added a log call in the composable)

[atomic helm]

yea but initial load from cold start?

even with the loading chip which was static would take a while

oh I was referring to before we added state changes when things were mainly static

[calm maple]

I haven't checked, we should probably launch the app with the profiler active some time

[atomic helm]

in that first PR IIRC simply adding the compose libraries added like 5 seconds of load time

[calm maple]

Unfortunately Android Studio freezes for me when I do that

[dire bough]

Yes! Been thinking this for a while, but have never actually checked it haha

But also because I've never used it before

[calm maple]

If it works it is pretty handy

[atomic helm]

I think I tried it on the phone app once

[calm maple]

If it doesn't it's a pain to figure out why it is broken so I haven't bothered yet

[dire bough]

I know there are supposed to be certain best practices to limit the amount of recompositions, but I have no idea whether we follow those

BTW how do we make dependabot update compose for wear automatically once the API is stable?

[dire bough]

Got it working, was straightforward once I figured out I needed to request focus haha

[atomic helm]

awesome!!

[dire bough]

Unfortunately I don't notice any performance improvements

[atomic helm]

😢

[dire bough]

I do feel that we should work on limiting the number of recompositions. I feel that that seems to hamper the performance a lot

[atomic helm]

i thought we cut down on most of them when we assigned the keyed indexes to the items recently?

I wonder if the websocket change to subscribe to entities we actually care about will help alleviate some of that performance too

or do we think the main home page is just too much? whats odd to me is that even when the loading chip shows up by itself it takes sometime...although first boot of the app is different than subsequent boots lol

[calm maple]

Most of the Wear app actually loads on the main home page, because everything happens in the MainViewModel

[atomic helm]

ive been thinking more about prioritize internal functionality, what do we think about only applying the logic when we cannot determine location permissions? Meaning if the user enabled it but we can still read the SSID then ignore the setting. Its not a big issue when it comes to API calls because we loop through and silently fail but it seems to trip up users more when it comes to loading the frontend. I was thinking maybe we need to add a check here to help alleviate the majority of the issues https://github.com/home-assistant/android/blob/master/app/src/main/java/io/homeassistant/companion/android/webview/WebViewPresenterImpl.kt#L49

[dire bough]

I now added a circular progress thingy for the loading view. There you see that it restarts a bunch of times during the loading. So I assume that is due to recompositions (maybe related to viewmodel actions?)

[atomic helm]

yea it must be, we have a lot of loops lol...i was hopeful the keyed indexes would cut down the recompositions

[calm maple]

Unfortunately it looks like Google made changes to interfaces which makes it harder to implement it, my code will definitely require some changes 😦

[dire bough]

Ahh that's crappy... Hopefully it's not too much additional effort!

[calm maple]

rc02 will require more changes because they changed the defaults according to the release notes

And because everything is marked as internal I had to copy some of the default code in order to be able to override it

[atomic helm]

I always assume theres more hidden unknown changes on each bump so I try to test as much as possible....if its a UI dependency I check each screen...been bit a few times lol

[dire bough]

I think I've checked every screen with my PR, but would be great if others can double check 🙂

[calm maple]

The spinner doesn't restart for me?

[dire bough]

This is much quicker than on an actual device (or mine at least), so that might be why

[calm maple]

And I thought the emulator was slow...

[atomic helm]

on my fossil the rotary input doesnt move much, it works but doesnt scroll like it used to using the latest debug APK

it sorta inches up and down but by inches i mean milimeters lol

[dire bough]

Hmm interesting... The new API for rotary events calculates the amount of pixels for us. On my galaxy watch it seems very similar to what we had before

So not too sure what to do about it

[atomic helm]

ah right I think there was a fallback in the old code

my fossil watch i think is like the bare minimum API level lol

I think if it works on other watches its probably something that google needs to correct on their end, the bug that I opened is not marked as fixed yet either so have to imagine they got more fixes coming

[dire bough]

Could be indeed. But it remains strange to me that it would differ that much per device

What kind of fallback did you use? I saw a different function call for older versions indeed, but did you do anything to correct for the scroll factor as well?

[calm maple]

Because the min SDK was bumped it actually shouldn't ever use 'older versions' function? Previously the minimum was 25, now 26, and the RotaryEventDispatcher only uses the fallback when not on SDK 26+

[atomic helm]

oh hmm my watch is on API 28

[calm maple]

Also looking at Compose's source code it is using the same function as was previously included in the app to calculate the amount of pixels

[atomic helm]

wow my watch had an update lol maybe thats why i couldnt scroll lol

honestly thought fossil was done updating this thing 😂

no scroll differences after the update, still moves a tiny amount

intesting that the implementation is similar yet my results are not lol

yea compared to latest beta on play store scrolling a big difference at least on my device

[dire bough]

That's really weird... Any thoughts on how to fix it?

[atomic helm]

looking at the People In Space repo that google linked me to in my issue it seems they are using a new google library called Horologist which seems to have its own unique type of composables....not sure if that library is doing anything extra on top of what the compose libraries does

https://github.com/joreilly/PeopleInSpace/tree/main/wearApp ive been using this app for guidance on the rotary input changes I made prevoiusly

[dire bough]

Your example doesn't seem to use onRotaryScrollEvent

There is one example in the Horologist library, which seems to do the same as my implementation: https://github.com/google/horologist/blob/790dc62f1abac9f56acc1c01d64472a5dd212abe/audio-ui/src/main/java/com/google/android/horologist/audio/ui/VolumeScreen.kt#L125

[atomic helm]

yea i dont get it either

[dire bough]

Maybe you can try changing animateScrollBy to scrollBy on line 38 of ThemeLazyColumn.kt?

Could be that the animation doesn't play nice with your particular watch/crown

[calm maple]

This code also uses scrollBy instead of animateScrollBy

@atomic helm, does scrolling with the crown work correctly in the example app?

[dire bough]

True, I changed it to the animated version when I noticed that that is also what Samsung seems to do by default and it looks a bit nicer. But if it gives problems then I'll just revert to normal scroll action

[atomic helm]

havent checked the example app, but it works correctly in our prod version

im checking the previous commit in the PR now

[calm maple]

Production also uses scrollBy...

[atomic helm]

yup that was it

debug APK from previous commit in the PR before we cahnged to animated scrolls as expected 🙂

[dire bough]

Alright! Too bad, but then I'll revert it in a bit

[atomic helm]

yea you wouldnt expect it to misbehave like that for an animation lol

scrolling feels a lot smoother than before

[calm maple]

Maybe it is due this bug, if using the rotary input produces multiple scroll events? I can imagine that it depends on the device how rotating the wheel is translated to 1 or more scroll event(s) https://issuetracker.google.com/issues/220119990

[atomic helm]

that makes sense

[dire bough]

Nice find! That makes a lot of sense indeed

[sinful creek]

Hi guys! I have a question.

[atomic helm]

sure just go ahead and ask 🙂 but keep in mind this is a development channel so theres no support here unless your writing code

[sinful creek]

lol, I forgot to hit send for my message 😆

Would it be possible to have more frequent (battery) sensor updates on Wear OS while charging? Maybe every 1 minute?

(I'm asking this here because I'm also a developer, so I'm interested in the technical details 🙂)

Basically it could be the same as the "Fast While Charging" setting on the phone app

But I'm not sure if Wear OS would allow a background task to be this frequent

[calm maple]

The main app uses Intent.ACTION_TIME_TICK to achieve this, so you could add it to the Wear intent receiver for the sensor worker in the app class and try it out

Based on my experience with the emulator though connectivity is limited when the screen is turned off, and if it's not possible to reliably send the new data, more frequent updates don't make sense

[calm maple]

@atomic helm in #android-archived:

I wonder if we need to look into adding a mechanism to check for existing widgets and remove as needed, we must have more users who have lingering widgets
I don't really see an option to see if a widget is 'active' in the AppWidgetManager, did you have any ideas on how to do this?

[atomic helm]

Upon first look at the docs do you think we can leverage getAppWidgetIds and compare to the DB? https://developer.android.com/reference/kotlin/android/appwidget/AppWidgetManager#getappwidgetids I have been trying to think of a good way to combat it since we first had to add https://companion.home-assistant.io/docs/troubleshooting/faqs/#seeing-toast-messages-for-configured-entity-not-found

[calm maple]

Not sure how I missed that, looks exactly like what is needed

That would also allow for removing the 'delete widget' button, which right now seems to confuse some people

[atomic helm]

I was thinking the same thing, how did I miss this last time 😂

yea that was why the delete button was added

[calm maple]

Also I'm pretty sure those Toasts have been removed and it now shows an icon on the widget instead

[atomic helm]

oh thats right, then we can get rid of that step 🙂

[atomic helm]

yea the only toast message we have now is when a service call fails

PR to remove that step https://github.com/home-assistant/companion.home-assistant/pull/766

[sinful creek]

guys, when can I expect the next Android beta release?

how often do you release beta?

[atomic helm]

the play store beta push happens every saturday at 9pm PST, then it depends on when google approves..sometimes an hour sometimes a few days

on github the same signature is used as the play store so you can always grab the latest beta apk from the releases tab and it will update properly

[sinful creek]

ohh, nice! that's good to know, thanks! 🙂

[dire bough]

What is the best way we can alert our users to new and somewhat hidden functionality in the Wear OS app? Thinking of long press for more options, complications and html markup for template tile (soon).

[sinful creek]

maybe the changelog? 😄

[dire bough]

Well Wear doesn't have an in-app changelog and I wonder how many people read the Play Store changelog haha (I don't)

[sinful creek]

I mean the in-app changelog on the phone app

I think the majority of the users of the WearOS app have the phone app installed as well

[dire bough]

I believe we currently don't put the Wear changes in there, but maybe we should indeed. What do you think @atomic helm can we add it under a separate section in the changelog?

[atomic helm]

yea we can add it to the change log, i'll see if I can update my existing PR to add a new section today

[atomic helm]

looks like we can't show a separate release section alongside the phone changelog

we can try this and see how users like it

they are technically part of the same release, just a different APK

[calm maple]

Can you do nested bullet points?

[atomic helm]

doesn't seem like it based on the docs and sample code from the library we are using https://github.com/AppDevNext/ChangeLog

[calm maple]

Also just noticed that the dialog borders are a different shade of grey than the list

[calm maple]

The screenshot in the readme file does show multiple headings...

[atomic helm]

ah had to add the versioncode

[atomic helm]

hmm not sure why its different, the code used for the theming on dark mode was taken from the sample

[sinful creek]

I was wondering if we could show the charging state (⚡) on the Battery Level sensor's icon we send to the server from the Android app, similarly to the iOS/macOS app.
I took a quick look into BatterySensorManager.kt and I think it could be easily implemented.
(on the screenshot, my phone is actually plugged into a charger)

If there are no objections, I'll implement this and create a PR 🙂

And there are icons separately for wireless charging (🆒)
I'll definitely want to utilize them 🙂

[dire bough]

Sounds like a nice improvement!

[calm maple]

You're talking about the app's sensor settings interface I presume? The app already sets icons which show the percentage for the server (your screenshots are from the frontend)

Nevermind, I just realised we don't show the charging bolt ⚡

[sinful creek]

I reworded my message to make it obvious for future readers 😄

[calm maple]

Remembered that icons sent to the server also show up in the app, I added that feature myself, so the first question makes no sense 😅

[sinful creek]

and do you agree that I should add a separate icon for wireless charging? I think it would be a nice extra touch

[calm maple]

Sure, there's already a sensor for the charger type that shows wireless charging but updating the battery level icon is indeed a nice touch https://github.com/home-assistant/android/blob/master/common/src/main/java/io/homeassistant/companion/android/common/sensors/BatterySensorManager.kt#L193-L198

[sinful creek]

The macOS/iOS app removes the bolt from the icon when the battery is at 100%, which is not practical in my opinion.

If you ask me, I would still display the ⚡ when the device is plugged in to the charger, even when it's technically "not charging". (that fact can be seen by looking at the "100%" text)

Or is it more important to have feature parity between the two platforms? (in that case, we could ask the iOS guys to change it 😛)

[sinful creek]

it's Almost Done™

but there's a problem...

the icon only updates whenever the battery level changes

[calm maple]

That is by design (it only pushes updates if the state actually changes)

You could work around it by setting lastSentState to something different but it's not really desirable

[sinful creek]

I was able to solve it by introducing a new DB property called last_sent_icon (in addition to last_sent_state)

it requires a DB migration...

[atomic helm]

the main reason why we introduced last_sent_state is because we hit cases where numerous updates were being sent if an intent trigger kept firing....the goal was to reduce the amount of sensor updates being sent unless the state of the sensor had changed...thats why a lot of the sensors had their attributes split up as the attributes can only describe the state so they should only update when the state has changed. We need to make sure we don't crazy with updates as it has caused issues in the past.

[sinful creek]

I created a draft PR with my changes, please take a look at it:
https://github.com/home-assistant/android/pull/2661

FYI: I tested it pretty carefully, and it was working correctly.

[atomic helm]

did you by chance check the upgrade path for a user? where you start from a fresh install of master and then upgrade to your branch? I always find that a good test to get any upgrading issues related to the migration

[sinful creek]

I only checked the upgrade path from master, but not the fresh install of my version

[sinful creek]

whenever you have time, could someone please review my PR? 🙏

[sinful creek]

thanks, @atomic helm !

[atomic helm]

np 🙂

[calm maple]

I noticed your review request yesterday but didn't have time to check it, sorry. Added another review just now 🙂

[sinful creek]

I'm not sure you if mean you added comments, because I can't see any new comments, just an approve 🤔

[calm maple]

No comments for my review

It works as expected, and the code also looks good to me, so simply ✅

[sinful creek]

guys, is there a planned date for the 2022.7 release?

[atomic helm]

for the android app it depends, theres no real set schedule unless theres a feature that depends on HA core

we do have a good amount of features to get out there, since we have quite the breaking change with respect to notification commands we do need a blog post to highlight those changes

[calm maple]

Even more changes for a blog post since the last one was for 2022.2 🙂

[atomic helm]

yea lol its been a minute, the nice thing is that the changelog sorta speaks for itself most of the time but we dont have a lot of space for breaking changes highlights lol

[sinful creek]

Could someone please merge it? It already has 2x approves 😇

(or did I miss something that we should wait for?)

[atomic helm]

we actually wait for a final review from Justin....typically over the weekend unless hes busy

[sinful creek]

ohh, I see 🙂 thanks for the info

[atomic helm]

https://android-developers.googleblog.com/2022/07/Final-Android-13-Beta-update-official-release-is-next.html?m=1 nice to see official release is coming up, probably next month I imagine?

[calm maple]

Wondering if the release for Pixels is in the first week of the month as usual, or slightly delayed like last year

Either way, I have to hurry up with the notification changes 😅

[atomic helm]

yea notification changes is what bit me last time we had a target SDK bump lol

[atomic helm]

yea first monday of august does seem a bit close, it may even get pushed back to Sept

[calm maple]

Yes there are some rough edges

The predictive back gesture still isn't enabled, and it's the first 'major' feature with a dedicated page on d.android.com

(Looks like they updated the documentation, it'll now arrive after the final release)

[deft jewel]

@green aurora some new notification sounds if you want https://www.reddit.com/r/apolloapp/comments/vvyhiv/wow/ifq4a11/

[green aurora]

haha, those are great

[misty crag]

Hi! We're currently looking into our dialogs.
And I was wondering if there is an easy way we could make (some of) our dialogs native?
For example confirmation dialogs with two or one buttons. And dialogs that could load our dialog content, for example more-info dialog.

[atomic helm]

Just to clarify you mean using a frontend dialog that triggers things in the app? or vice versa with the app sending data back to HA frontend?

[misty crag]

Yeah, when HA frontend opens a dialog. For example a confirmation dialog like this

Or a full screen dialog like this

[atomic helm]

So in these cases if the user is in the HA interface we can listen to the External Bus for messages, we do that today but we can always add more. Right now external bus is used for displaying the Companion App settings option, processing different haptic responses, notifying the app if the frontend is connected and also NFC (might be missing a few other things)

[misty crag]

Would be nice to give our apps a bit more native feeling. So if it’s doable and reliable I think we should discuss this with some folk.

[atomic helm]

oh so you mean to move away from our native screens that we have like for settings where users can configure other bits of android like widgets and sensors etc...

[calm maple]

A simple dialog with text and yes/no (first screenshot) or a lot of different content/web elements (second screenshot) does make a difference though - the second one is much harder, at least on Android

[calm maple]

I'm assuming 'native' refers to iOS/Android = native, not HA frontend = native. Based on your description you're thinking HA frontend = native?

[atomic helm]

yup I was thinking HA frontend being native 🙂

[green aurora]

i think we could reasonably do the more info in a native modal of some sort if we can avoid a secondary websocket connection. otherwise it would feel slow to load again a second time to show it.

[calm maple]

Full screen dialogs like more info are already close to how a similar dialog would be presented on Android, so the required changes would also be different for each platform

On iOS more info would presumably be shown as a sheet on top of the dashboard?

[fallen crown]

I'm curious what would be different visually if iOS or Android handled it?

I feel like by making the alert match the device it will look out of place

[mossy furnace]

Hey, mdi icons where updated to version 7.0.96 (https://dev.materialdesignicons.com/changelog#version-7.0.96) just now, there are some breaking changes, I didn't check everything yet, but at least the iOS app uses 1 icon that will be removed: https://github.com/home-assistant/iOS/blob/master/Sources/Shared/API/Webhook/Sensors/LastUpdateSensor.swift#L17

We should check and update the mobile apps, I think we did that before right? I hope there are no renames that affect us, as that would require some version check logic and stuff....

[mossy furnace]

Regex for finding them:

mdi:android-messages|mdi:book-variant-multiple|mdi:desktop-mac|mdi:desktop-mac-dashboard|mdi:discord|mdi:diving-scuba|mdi:email-send|mdi:email-send-outline|mdi:email-receive|mdi:email-receive-outline|mdi:format-textdirection-r-to-l|mdi:format-textdirection-l-to-r|mdi:google-controller|mdi:google-controller-off|mdi:google-home|mdi:lecturn|mdi:receipt|mdi:receipt-outline|mdi:tablet-android|mdi:text-to-speech|mdi:text-to-speech-off|mdi:timeline-help|mdi:timeline-help-outline|mdi:vector-point

[green aurora]

i'll need to update MDI in the app, that sensor value, and add a migration to the icons the app has. pretty simple at least.

[calm maple]

For the Android app it should be limited to 1 (other) icon as well https://github.com/home-assistant/android/blob/master/app/src/main/java/io/homeassistant/companion/android/sensors/AudioSensorManager.kt#L221

and potentially icons users have selected for widgets on their device...

[dire bough]

For android the library we use for mdi icons still needs to be updated I think. Last time I made a PR there myself, so I'll probably have a go at that soonish again

[atomic helm]

that and also notification icon

[calm maple]

Widget icons is also problematic, it's still on version 5.x with no clear upgrade path (it's using another, second library which hasn't been updated)