16:00:03 <rainemak> #startmeeting Sailfish OS, open source, collaboration -- 25th September 2025
16:00:04 <sailbot> Meeting started Thu Sep 25 16:00:03 2025 UTC. The chair is rainemak. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:04 <sailbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:00:04 <rainemak> #info Meeting information and agenda can be found here:
16:00:04 <rainemak> #link https://forum.sailfishos.org/t/community-meeting-on-25th-september-2025/24781
16:00:04 <rainemak> I am the meeting's chairperson today, and will be doing my best to keep time and order. Please respect the timings and bee-hive.
16:00:04 <rainemak> #topic Brief introduction (5 min). Please prefix your name/handle with #info
16:00:32 <ExTechOp> #info Otto Mäkelä, community
16:00:55 <rainemak> Missed few seconds... I have usually on time on this, please feel free say about the delay.
16:01:00 <direc85[m]> #info Matti Viljanen, Jolla
16:01:05 <rainemak> usually been on time
16:01:07 <Cryx[m]> Hello... Cryx - Community...
16:01:15 <rainemak> #info Raine Mäkeläinen, Jolla
16:01:57 <Venty[m]> # Info Venty - Community
16:02:12 <FireFly> #info FireFly - Community
16:02:21 <rainemak> We have five topics today. Let's try to respect requested time slots so that we can cover them all.
16:02:23 <Cryx[m]> Sorry, forgot the #info Cryx, Community
16:02:58 <rainemak> I think did not extend any of them. For one I chose the longer one.
16:04:31 <rainemak> I'm very pleased to see so many topics. Let's stay on this course.
16:05:00 <rainemak> #topic The future for Xperia 10 series devices beyond the IV and V (5 mins -- PeegeeTips)
16:05:12 <rainemak> #info <PeegeeTips> Is the J3 a new direction for Jolla; moving to selling
16:05:12 <rainemak> #info <PeegeeTips> factory-flashed and bootloader locked devices?
16:05:12 <rainemak> #info <PeegeeTips> It has been suggested by Xiaomi that they’re ending their
16:05:12 <rainemak> #info <PeegeeTips> bootloader unlocking function to maintain compliance with EU
16:05:12 <rainemak> #info <PeegeeTips> regs in the digital safety act. Does Jolla consider this a
16:05:14 <rainemak> #info <PeegeeTips> threat to their existing business model, such that they are
16:05:17 <rainemak> #info <PeegeeTips> moving away from selling device licences to pre-flashed
16:05:19 <rainemak> #info <PeegeeTips> devices? I ask as Sony continues to release new versions of the
16:05:21 <rainemak> #info <PeegeeTips> 10 series, and they remain well built and and affordable
16:05:23 <rainemak> #info <PeegeeTips> mid-range handsets:
16:05:25 <rainemak> #link https://www.gsmarena.com/sony_xperia_10_vii-review-2879.php
16:05:27 <rainemak> #info <Jolla> Good question but difficult to give you a good answer. We have not
16:05:29 <rainemak> #info <Jolla> said that we are moving away from downloadable & flashable
16:05:31 <rainemak> #info <Jolla> Sailfish OS images. At this point, we do not have an update
16:05:33 <rainemak> #info <Jolla> regarding the next downloadable & flashable Sailfish OS image.
16:06:06 <rainemak> Based on forum comments it looks that Fairphone could plausible be a good candidate for the future. No decisions made.
16:07:42 <ExTechOp> Has any contact been made with the Fairphone people? I understand the hardware spec is pretty open.
16:08:03 <rainemak> I think we, as Jolla, shall think how do we enable AppSupport for some community ports so that it would be a business for us. Trust me, have spend quite a bit on tinkering that.
16:08:44 <rainemak> ExTechOp, unfortunately I rather not open those discussions.
16:09:00 <ExTechOp> ;-D
16:09:47 <rainemak> We have a good communication with Sony Open Device Program.
16:10:21 <ExTechOp> Though, not good enough to have them push new firmware?
16:10:46 <rainemak> ExTechOp, it's not like that.
16:11:49 <rainemak> Like said, let's try to respect reserved time slots. We can come to topics that were left at the end in Generic discussion.
16:12:09 <rainemak> let's move on
16:12:16 <rainemak> #topic Speed up a Device (5mins -- Cryx)
16:12:16 <rainemak> #info Plausible substitute Seven.of.nine
16:12:26 <rainemak> #info <Cryx> There is that thread in the forum for some time now, and I wonder if
16:12:26 <rainemak> #info <Cryx> anyone from Jolla ever looked a this. I also feel the handling of
16:12:26 <rainemak> #info <Cryx> SFOS is sometimes slow and would like to see some things happening
16:12:26 <rainemak> #info <Cryx> faster. And as these things seem to be tied into the system and force
16:12:26 <rainemak> #info <Cryx> a device to (re-) act slow I ask myself why…
16:12:28 <rainemak> #info <Cryx>
16:12:29 <rainemak> #info <Cryx> I will sadly be on work travel that day so I don’t know if could make
16:12:31 <rainemak> #info <Cryx> it into the meeting (nevertheless I will try) , but I missed to point
16:12:33 <rainemak> #info <Cryx> to this topic already three or four times. On the other hand
16:12:35 <rainemak> #info <Cryx> everything relevant is already said in the linked thread, so the main
16:12:37 <rainemak> #info <Cryx> questions are:
16:12:39 <rainemak> #info <Cryx>
16:12:41 <rainemak> #info <Cryx> - Is Jolla aware of this topic?
16:12:43 <rainemak> #info <Cryx> - Is there anything that stands against bringing such speed up tweaks
16:12:47 <rainemak> #info <Cryx>   into the system with a SFOS update for all users?
16:12:49 <rainemak> #link https://forum.sailfishos.org/t/speed-up-a-device-by-system-tweaks-in-the-qml-files/19769
16:13:26 <abr> The one for the notes app could be a PR now :)
16:13:57 <rainemak> ^ PRs or generic please
16:14:02 <rainemak> #info <Jolla> Yes, we aware of this topic and we understand reasoning that you have.
16:14:32 <rainemak> #info <Jolla> Practical thing that stands in between of implementing this is
16:14:32 <rainemak> #info <Jolla> resourcing and time. When done properly, we'd review (evaluate) and
16:14:32 <rainemak> #info <Jolla> verify each change on each officially supported devices. Usually
16:14:32 <rainemak> #info <Jolla> during review there would be discussion whether this or that look
16:14:32 <rainemak> #info <Jolla> better. Then we'd repeat after plausible adjustments. The whole
16:14:34 <rainemak> #info <Jolla> process takes much more time than sed'ing changes to the device.
16:14:35 <rainemak> #info <Jolla> Implementing this so that we'd have device spefic variants is no go.
16:15:29 <rainemak> I'm all for reducing animation times but it takes time.
16:17:02 <rainemak> 5 mins for a slot is definitely too sort.
16:17:13 <rainemak> slot == topic
16:18:15 <rainemak> Yes, this is acknowledged. Anything to add?
16:18:51 <rainemak> 2mins extra
16:18:58 <rainemak> more like a minute
16:19:21 <Cryx[m]> No, as most was said in the topic.
16:19:21 <Cryx[m]> But agreed, that device specific changes are not good...
16:19:54 <rainemak> Cryx[m], device specific things are extremely time consuming to handle
16:20:15 <Cryx[m]> Fully understandable...
16:20:29 <rainemak> Like said, we can continue random discussion on Generic topic at the end
16:20:35 <rainemak> moving on
16:20:43 <rainemak> #topic Cell Broadcast alerts (5 mins -- asked by CLMA31)
16:20:43 <rainemak> #info <CLMA31> There has been multiple reports that cell broadcast alerts aren’t
16:20:43 <rainemak> #info <CLMA31> working: Cell Broadcast alerts (Germany) - #165 by davidrasch. Is
16:20:43 <rainemak> #info <CLMA31> this known problem and if so is there any idea how to mitigate this
16:20:43 <rainemak> #info <CLMA31> problem?
16:20:44 <rainemak> #link https://forum.sailfishos.org/t/cell-broadcast-alerts-germany/13528/165
16:20:53 <rainemak> We need to check are AIDL and HIDL based devices implemented right. So, it is also
16:20:53 <rainemak> that much device adaptation specific. Based on discussion comments this could be
16:20:53 <rainemak> AIDL related issue. To be confirmed.
16:21:45 <mal> it's difficult to test since those alerts happen rarely
16:21:47 <rainemak> Do we have mal on the line? Maybe he have some ideas / thoughts?
16:21:51 <piggz[m]> I can confirm not getting UK alerts, using my Volla port and the binder driver ... no logs unfortunately
16:22:01 <mal> piggz[m]: aidl or hidl?
16:22:13 <piggz[m]> hidl i think
16:22:25 <abr> last I heard you had to subscribe to the right broadcast channels
16:22:43 <mal> yes, that needs to be checked if that works correctly
16:22:53 <rainemak> piggz[m] and abr , nice to see you both
16:23:08 <mal> unfortunately I haven't heard anyone would have gotten debug ofono logs from those alert tests
16:23:37 <piggz[m]> :) .. i forgot the time, and just sawthe meeting happened! .. you should make a way to subscribe to a calendar invite for the meetings
16:23:49 <rainemak> maybe just maybe, we could try to simulate thing for example with local HÄKE (emergency center)
16:23:59 <abr> there's an ics calendar on the sfos wiki!
16:24:14 <piggz[m]> oh cool
16:24:21 <rainemak> abr, could you paste the link please
16:24:32 <rainemak> use #link prefix
16:24:43 <rainemak> please
16:24:47 <abr> #link https://docs.sailfishos.org/Support/community.ics
16:24:51 <rainemak> +1
16:25:02 <rainemak> abr, kiitos :-)
16:25:10 <abr> we should put that in the room topic maybe?
16:25:19 <rainemak> let's do so
16:25:33 <rainemak> it's time to move forward
16:25:42 <abr> sorry for the distraction!
16:25:52 <rainemak> #topic Android apps mobile data connection problems (10 mins -- asked by CLMA31)
16:25:52 <rainemak> #info <CLMA31> It seems that there has been a lot of discussion in history related
16:25:52 <rainemak> #info <CLMA31> to the data connection problems inside the AAS. Has Jolla been able
16:25:52 <rainemak> #info <CLMA31> to identify main reason for the problem and is there what kind of
16:25:52 <rainemak> #info <CLMA31> development plan related to that? Will 5.1 update bring
16:25:54 <rainemak> #info <CLMA31>improvements to the situation? If I have understood correctly
16:25:55 <rainemak> #info <CLMA31> sometimes the problems occur if you switch between WLAN and mobile
16:25:57 <rainemak> #info <CLMA31> data and sometime the problem occurs randomly. As many people
16:25:59 <rainemak> #info <CLMA31> still rely to some Android apps and new comers even more, reliable
16:26:01 <rainemak> #info <CLMA31> internet connection is quite crucial. Here are some topics from
16:26:03 <rainemak> #info <CLMA31> the forum I found:
16:26:05 <rainemak> #link https://forum.sailfishos.org/t/4-6-0-13-xperia-10-iii-android-apps-mobile-data-connectivity-worse-then-ever/19311/34
16:26:08 <rainemak> #link https://forum.sailfishos.org/t/no-mobile-internet-with-android-apps-on-c2/20586/75
16:26:10 <rainemak> #link https://forum.sailfishos.org/t/release-notes-tampella-5-0-0-68/23427/22
16:26:12 <rainemak> #link https://forum.sailfishos.org/t/release-notes-tampella-5-0-0-70-jolla-c2-only/24477/19
16:26:24 <rainemak> #info <Jolla> Thank you for bring this up. Tracked already on several fronts.
16:26:24 <rainemak> #info <Jolla> There seems to be something operator specific involved but we have
16:26:24 <rainemak> #info <Jolla> not yet figured what triggers / causes it.
16:26:24 <rainemak> #info <Jolla> That said, we have a different kind of implementation approach in
16:26:26 <rainemak> #info <Jolla> internal testing which is similar to the approch that we had years
16:26:28 <rainemak> #info <Jolla> ago (maybe it was around XA2, Xperia 10, Xperia 10 II). A lot of
16:26:30 <rainemak> #info <Jolla> things have changed since.
16:27:00 <rainemak> If this approach is good, we target to roll it for Jolla C2 5.0. The change is
16:27:00 <rainemak> not yet ported for older devices, and frankly I don't have an effort estimate
16:27:00 <rainemak> for porting and testing it for all devices. I don't know the internals of the
16:27:00 <rainemak> implementation but it may have AIDL vs HIDL differences.
16:27:00 <rainemak> So far this new approach has been rock solid on my Jolla C2 device. To be said
16:27:02 <rainemak> that I am mostly testing mobile data only as that caused most issues for me.
16:30:14 <rainemak> IMO AppSupport do not need to know exact connection type. Root cause looks to be somewhere in the mobile operator data. How it is coming and what bits it provides. For some people, they do not have any issues and for example I had it quite frequently.
16:30:39 <rainemak> As we didn't quite figure the root cause, we took the alternative path.
16:30:55 <rainemak> It'll be far better already.
16:31:04 <abr> and more stable across different devices
16:31:15 <direc85[m]> AppSupport should be aware of if it's on WLAN or mobile data, that affects some apps' data usage.
16:31:27 <rainemak> not yet across devices as we have not ported it to different devices
16:31:44 <rainemak> direc85[m], that's a nuance nowadays
16:31:50 <abr> but when you do, it should be more consistent
16:31:58 <rainemak> in Europe flatrate is a standard
16:32:29 <rainemak> direc85[m], data usage control is anyways visible in Sailfish OS side
16:32:36 <abr> yeah but some apps really want to know which one they're on. early on we tried just calling it ethernet, but some apps refused to work properly.
16:33:19 <rainemak> Now we'd calling it wlan which helps a bit (compared eth)
16:34:13 <rainemak> mobile data would be kind of on and mimic'ed for the AppSupport
16:34:16 <direc85[m]> Deezer for example has different settings for WLAN and mobile data behavior. The difference in data usage can be substantial.
16:34:33 <rainemak> direc85[m], with this approach it wouldn't matter
16:34:56 <rainemak> if you want to be on WLAN then you go to WLAN
16:35:21 <rainemak> WLAN takes always precedence over mobile data anyways
16:35:42 <rainemak> direc85[m], like said this will be already much better.
16:36:21 <direc85[m]> rainemak, that's good
16:36:29 <rainemak> target is that we'd have some sort of a toggle for you so that you can choose whether you take the fallback or try respect the mobile data
16:37:39 <rainemak> surely, when traveling this might be a issue but same applies to Sailfish OS -> if you have denied roaming then you don't have mobile data
16:38:07 <rainemak> 2mins (5mins again not enough)
16:38:56 <rainemak> I can go to extra time, no worry there
16:39:37 <rainemak> direc85[m], I can through these packages to you as well if you have phased this issue.
16:39:54 <rainemak> ^ let's take offline
16:40:20 <direc85[m]> rainemak, sure, let's get back to it later
16:40:32 <rainemak> I'm pretty sure that after these topics we have plenty for general / generic discussion... let's move on
16:40:37 <rainemak> #topic Open Pull Requests (PRs) to discussion (2 mins -- asked by Jolla)
16:40:51 <rainemak> reduced to two mins on the fly
16:41:03 <rainemak> instead of usual 5
16:41:49 <rainemak> I can say that gcc13 is close to get it. Maybe even today evening.
16:42:53 <rainemak> get in
16:44:16 <rainemak> Oh, I missed one. I take the GPS topic next in a minute
16:44:29 <rainemak> My bad
16:45:22 <rainemak> #opic Timeline of GPS development (5mins -- asked by CLMA31)
16:45:22 <rainemak> #info <CLMA31> @hildon has asked clarification on GPS development on C2. My guess
16:45:22 <rainemak> #info <CLMA31> is that this is regarding A-GPS implementation which has been
16:45:22 <rainemak> #info <CLMA31> talked by @Rainemak in Open source discussion. I guess the main
16:45:22 <rainemak> #info <CLMA31> interest is to ask if the A-GPS will be implemented already in
16:45:24 <rainemak> #info <CLMA31> next release?
16:45:35 <rainemak> This one before General discussion
16:45:40 <rainemak> #link https://forum.sailfishos.org/t/sailfish-community-news-18th-september-2025-issue-reporting/24830/11
16:45:40 <rainemak> #link https://forum.sailfishos.org/t/open-sourcing-proceeding/24689/39
16:45:50 <rainemak> To clarifi first, A-GPS is supported on all devices (more or less). It could well
16:45:50 <rainemak> be that it is not working/functioning properly for all devices. There are two
16:45:50 <rainemak> things that are relatively simple to tackle. Updated SUPL server (hopefully we
16:45:50 <rainemak> don't end up having adaptation specific SUPLs) and offline/online data providing
16:45:50 <rainemak> fixed location points. Former provides satelite position information through
16:45:52 <rainemak> Internet rather from satelites themselves (low bandwidth). Later providing
16:45:53 <rainemak> fixed location points that are usually mobile cell towers or wireless access
16:45:55 <rainemak> points. Cell tower triangulation can be used to narrow down location rather
16:45:57 <rainemak> close precise location.
16:46:58 <rainemak> #info If you do not mind, I'll extend the meeting by 10mins
16:47:45 <direc85[m]> rainemak, the reply doesn't have the usual prefix
16:47:50 <mal> just to mention that the location obtained from external sources like MLS (beacondb or whatever) is inserted via gps android api and device hardware gps can then use that as help for getting location sooner, what actually happens inside the firmware is not really known
16:48:28 <mal> rainemak: typo in topic it probably didn't get logged correctly
16:48:54 <mal> and didn't change the topic
16:49:57 <rainemak> replay
16:50:04 <rainemak> copy-paste error
16:50:29 <rainemak> <rainemak> #topic Timeline of GPS development (5mins -- asked by CLMA31)
16:50:29 <rainemak> <rainemak> #info <CLMA31> @hildon has asked clarification on GPS development on C2. My guess
16:50:29 <rainemak> <rainemak> #info <CLMA31> is that this is regarding A-GPS implementation which has been
16:50:29 <rainemak> <rainemak> #info <CLMA31> talked by @Rainemak in Open source discussion. I guess the main
16:50:29 <rainemak> <rainemak> #info <CLMA31> interest is to ask if the A-GPS will be implemented already in
16:50:30 <rainemak> <rainemak> #info <CLMA31> next release?
16:50:32 <rainemak> <rainemak> This one before General discussion
16:50:34 <rainemak> <rainemak> #link https://forum.sailfishos.org/t/sailfish-community-news-18th-september-2025-issue-reporting/24830/11
16:50:37 <rainemak> <rainemak> #link https://forum.sailfishos.org/t/open-sourcing-proceeding/24689/39
16:50:39 <rainemak> <rainemak> To clarifi first, A-GPS is supported on all devices (more or less). It could well
16:50:41 <rainemak> <rainemak> be that it is not working/functioning properly for all devices. There are two
16:50:43 <rainemak> <rainemak> things that are relatively simple to tackle. Updated SUPL server (hopefully we
16:50:47 <rainemak> <rainemak> don't end up having adaptation specific SUPLs) and offline/online data providing
16:50:49 <rainemak> <rainemak> fixed location points. Former provides satelite position information through
16:50:51 <rainemak> <rainemak> Internet rather from satelites themselves (low bandwidth). Later providing
16:50:53 <rainemak> <rainemak> fixed location points that are usually mobile cell towers or wireless access
16:50:55 <rainemak> <rainemak> points. Cell tower triangulation can be used to narrow down location rather
16:50:57 <rainemak> <rainemak> close precise location.
16:50:59 <rainemak> <rainemak> #info If you do not mind, I'll extend the meeting by 10mins
16:51:01 <rainemak> <direc85[m]> rainemak, the reply doesn't have the usual prefix
16:51:03 <rainemak> <mal> just to mention that the location obtained from external sources like MLS (beacondb or whatever) is inserted via gps android api and device hardware gps can then use that as help for getting location sooner, what actually happens inside the firmware is not really known
16:51:09 <Keto> no, not like that :)
16:51:20 <rainemak> #topic Timeline of GPS development (5mins -- asked by CLMA31)
16:51:20 <rainemak> #info <CLMA31> @hildon has asked clarification on GPS development on C2. My guess
16:51:20 <rainemak> #info <CLMA31> is that this is regarding A-GPS implementation which has been
16:51:20 <rainemak> #info <CLMA31> talked by @Rainemak in Open source discussion. I guess the main
16:51:20 <rainemak> #info <CLMA31> interest is to ask if the A-GPS will be implemented already in
16:51:22 <rainemak> #info <CLMA31> next release?
16:51:23 <rainemak> This one before General discussion
16:51:25 <rainemak> #link https://forum.sailfishos.org/t/sailfish-community-news-18th-september-2025-issue-reporting/24830/11
16:51:28 <rainemak> #link https://forum.sailfishos.org/t/open-sourcing-proceeding/24689/39
16:51:30 <rainemak> To clarifi first, A-GPS is supported on all devices (more or less). It could well
16:51:32 <rainemak> be that it is not working/functioning properly for all devices. There are two
16:51:34 <rainemak> things that are relatively simple to tackle. Updated SUPL server (hopefully we
16:51:36 <rainemak> don't end up having adaptation specific SUPLs) and offline/online data providing
16:51:38 <rainemak> fixed location points. Former provides satelite position information through
16:51:40 <rainemak> Internet rather from satelites themselves (low bandwidth). Later providing
16:51:42 <rainemak> fixed location points that are usually mobile cell towers or wireless access
16:51:44 <rainemak> points. Cell tower triangulation can be used to narrow down location rather
16:51:48 <rainemak> close precise location.
16:51:50 <rainemak> #info If you do not mind, I'll extend the meeting by 10mins
16:51:52 <rainemak> <direc85[m]> rainemak, the reply doesn't have the usual prefix
16:51:54 <rainemak> <mal> just to mention that the location obtained from external sources like MLS (beacondb or whatever) is inserted via gps android api and device hardware gps can then use that as help for getting location sooner, what actually happens inside the firmware is not really known
16:51:58 <rainemak> Keto, yeah sure
16:52:59 <mal> about supl server, it is usually defined by android side in gps configuration file, not sure what happens if it's not
16:53:37 <mal> also often android uses google supl server which of course might cause some privacy issues
16:53:59 <rainemak> mal, that's indeed a good point.
16:54:19 <abr> beacondb should make things much faster for the initial rough fix from a user point of view.
16:54:37 <rainemak> and same applies to SUPL server
16:55:21 <mal> our geoclue plugin does allow overriding the supl server defined by gps config file
16:56:26 <mal> I'll do some checking of the code for that part to verify if things work correctly like setting the server
16:56:45 <rainemak> back in the days when we had HERE assisted GPS it was a piece of software not in GPS ship. My gut feeling is that it's nowadays even more common to have the whole shebang as software
16:57:21 <rainemak> or at least partially a piece of SW on top of GPS HW
16:57:23 <mal> yeah, not sure what is done inside the google services in terms of location
16:57:54 <mal> it might have all kinds of things there hidden in the closed project
16:58:33 <abr> yes I wonder if android even uses the gps chip much anymore
16:58:59 <rainemak> nonetheless, there are room to improve and those small improvements should be relatively easy to tackle.
16:59:14 <FireFly> does this discussion affect SFOS in general (through libhybris) or moreso the appsupport/aliendalvik side?
16:59:35 <rainemak> I would not like call the release train yet, but if it is as simple as think maybe that could even land to 5.0.0
17:00:11 <mal> this is about sfos side, and appsupport gets location from sfos side anyway
17:00:17 <FireFly> *nod*
17:00:19 <rainemak> correct
17:00:50 <rainemak> I think this is covered and sorry for the copy-paste hassle
17:00:52 <mal> unless microg or something has some extra location things on devices which have it installed
17:00:53 <rainemak> #topic General discussion (10 mins)
17:01:00 <ExTechOp> Ceterum censeo, the glacial progress of the Xperia 10 IV / V port bug fixes.
17:01:00 <ExTechOp> A year ago we were waiting for Sony fixes, has anything really happened since? https://forum.sailfishos.org/t/confused-about-sony-xperia-10-v/19895/20
17:01:29 <rainemak> I think we do not much time for scheduling next meeting, so let's use this general wisely
17:02:37 <rainemak> ExTechOp, I'd say baby steps. We need to confirm some bits but we're not far.
17:03:11 <ExTechOp> You know I'm a very long-time user, but even so, I am getting impatient.
17:03:39 <ExTechOp> Also a quick side question to other SFOS users: Android software unexpected “backgrounding”, anyone else see this happening?
17:03:39 <ExTechOp> https://forum.sailfishos.org/t/android-software-unexpected-backgrounding/23149/1
17:03:47 <rainemak> ExTechOp, I feel you, I have been using Xperia 10 V as my daily as well
17:04:18 <abr> the wrong app launching you mentioned in that link is fixed for the next release!
17:04:49 <abr> in the meantime make sure you don't click more than one app launcher while appsupport is starting up
17:06:29 <ExTechOp> The bit with microG popping up is painful, I was out geocaching last weekend and it kept repeatedly happening.
17:06:31 <ExTechOp> It'd be nice if SFOS developers could note in that thread which parts of this is known stuff and which are weird things they've not seen?
17:07:59 <rainemak> ExTechOp, I have seen that happening as well
17:08:24 <rainemak> Let's see if we can figure out something
17:08:34 <ExTechOp> ✅
17:08:41 <yusssufff> As you mentionned HERE and its Agps, nowadays the Agps included in Pure Maps (from Huawei's appgallery) seems to work excellent on Sailfish (with AppSupport... I get a fix in seconds, even with Gps not open in the device.
17:08:54 <rainemak> Hey all, should start scheduling next meeting or do you need still more for this?
17:09:42 <ExTechOp> I think we're done. Two weeks from now works.
17:10:06 <rainemak> yusssufff, what do you mean Pure Maps + Huawei appgallery?
17:10:21 <rainemak> I do know Huawei App Gallery but that's an Android app
17:10:43 <yusssufff> It is a huawei app, distributed via its own appgallery (installable apk)
17:11:13 <ExTechOp> yusssufff I'm a bit confused, was that a reply to me since I did *not* mention HERE maps?
17:11:15 <rainemak> that shouldn't be able to influence Sailfish OS gps - I might miss something
17:11:34 <yusssufff> Yeah all android apps. Oh sorry my bad i misspelled, its named Petal Maps
17:11:43 <rainemak> ExTechOp, it was for me I think
17:12:24 <yusssufff> The surprizing part being that it finds you with Sailfish's gps off.
17:12:33 <FireFly> I've been meaning to try to figure out why getting a GPS fix takes a long time (~10 min, so seemingly no assist) each time despite having it enabled/installed.. but probably less of a meeting topic
17:12:40 <rainemak> yusssufff, then it's A-GPS not GPS
17:13:01 <piggz[m]> waydroid -can- affect sailfish GPS, so appsupport might be similar? ... sometimes it seems waydroid can lock out sailfish from reading gps
17:13:17 <yusssufff> Right right  Agps. But pretty amazingly working within this app
17:13:24 <rainemak> there are things like IP-based, WLAN-based, cell-tower-based positioning...
17:13:30 <abr> some of these things look up your connected cell towers and nearby wifi networks to get a fix. that's not gps at all.
17:13:52 <abr> but afaik appsupport isn't allowed to scan for wifi networks
17:14:04 <rainemak> yeap, same here
17:14:07 <yusssufff> Therr is also HMS core downloadable from Appgallery, that include the same Agps for other android apps to use
17:14:38 <rainemak> nonetheless, that is GPS positioning, it's A-GPS positioning broader context
17:14:46 <rainemak> nonetheless, that is not GPS positioning, it's A-GPS positioning broader context
17:15:13 <rainemak> alright, this is covered
17:15:27 <rainemak> #topic Next meeting time and date (1 mins)
17:15:37 <rainemak> Proposing Thursday 9th October at 04:00 PM UTC
17:15:38 <ExTechOp> Two weeks from now (the default, also already in the calendar mentioned above) works4me.
17:15:41 <rainemak> Usual biweekly
17:15:46 <rainemak> :-)
17:15:48 <direc85[m]> +1
17:15:55 <rainemak> #info Next meeting will be held on Thursday 9th October 2025 at 04:00pm UTC: 2025-10-09T1600Z
17:15:56 <yusssufff> Okay yes right. Anythow thats Huawei's tools that with Petal Maps or HMS can currently offer real good Agps on android apps wirh Appsupport.
17:16:40 <mal> piggz[m]: pretty sure waydroid uses gps via libs or binder directly which can mess up sfos side gps, unlike in appsupport which gets location via qtlocation
17:16:44 <rainemak> yusssufff, good to know, but it's not GPS. On Forum people tend to confuse GPS and A-GPS (heavily)
17:17:06 <piggz[m]> mal: yeah, thats what i suspected
17:17:33 <rainemak> mal, piggz[m], that's a completely different aspect
17:17:56 <piggz[m]> sure, i wasnt sure how appsupport was getting it, but if its like that then sure, unrelated
17:17:57 <abr> yes a lot of these things can't be shared so simply. that's why bluetooth in appsupport is so difficult. but that's another story.
17:18:05 <rainemak> 20mins extra this will be. I'll keep this scheduling open as discussion continued
17:18:11 <rainemak> so 2mins left
17:18:30 <yusssufff> Right
17:18:48 <abr> appsupport gets an emulated location provider instead, so it can share
17:19:42 <yusssufff> Well its always possible anyhow to advice folka to install Huawei Mobile Services HMS from Appgallery to get a good Agps. Maybe i'll make a forum thead about that..
17:20:07 <mal> that also means appsupport gets the location from any external source like beacondb mentioned
17:20:26 <rainemak> Once again my apologies regarding location topic... loved to see this vibrant discussion! You all rock!
17:20:35 <mal> because that is gotten via qtlocation the same way as any other location info
17:20:49 <rainemak> We the location topic covered as well I think.
17:21:14 <abr> beacondb should provide a similar experience to that huawei thingy
17:21:18 <rainemak> If you mal & yusssufff like to discuss still I can leave this open for a moment
17:21:24 <rainemak> or abr
17:21:31 <abr> i'm done :)
17:21:37 <mal> we can also continue on some other channel if needed
17:21:57 <rainemak> sure, but logs are good some people
17:22:14 <rainemak> Thank you all!
17:22:19 <rainemak> See you in two weeks
17:22:27 <ExTechOp> Thank you everyone!
17:22:29 <yusssufff> I'm done too :). Just adviae you folks to test Petal maps, thats quite a thing to get a fix in seconds on Sailfish 😉
17:22:47 <rainemak> #endmeeting