Hi,

Thought my experience might help some users considering pixel3a/UT use.

• My Daily Drive week after 3 weeks (Pre- March 2 Update for ofono issues) on Bell Canada network:

  • Battery: Solid, a little less than my Pixel3 on android but usage probably not same right now
  • GPS - working, but not "Rush Usable" due to delay to lock satellites (I understand that other OS's get rough location data from Cell tower triangulation and WIFI info)
    • Used uNav and OpenMaps ... pretty good
  • FingerPrint Unlock
    • Works well - Sometimes UI requires password again without a reboot (This request seems linked with WIFI dropping ... )
  • UI fast and responsive - although only reference is Pinephone
    • Had 4-5 lockups requiring reboot - probably would have resolved if I had been more patient
    • Webapps / Morph sometimes get laggy - need to be patient for a minute
    • Occasionally experience unlock delays - screen shows last app, need to wait 4 secs for it to be responsive to any inputs
    • WebApps are awesome and work to replace many android news apps
  • Screen
    • auto brightness works but seems to still consider manual slider position - need to manually adjust at night and in bright sun
  • Power
    • Power Off rarely works - restarts GUI on first try, then reboots on second. Haven't really tried too hard beyond this. Once or twice it powered down completely
    • Boot loader unlocked warning is still shown (apparently necessary)
    • Google Image still shown on boot
  • WIFI: On certain networks, frequently drops and prompts for password ... not needed to get back on, just re-click AP and it reconnects.
    • Happens frequently at office (Ubiquity multiple APs meshed), but not on a netgear DDWRT
  • Phone
    • Has been reliable
    • Switches down to 3G gracefully.
    • No volume control in call - very loud (uVolMan app?)
    • Echo for person on other end - need to investigate more: Had one person with issues, but may have been their side. Have had many calls with no complaints - could be simply the volume issue - too loud? (should test with headset...)
    • 3.5 trrs headset works
  • Hotspot
    • works well
  • Bluetooth:
    • Phone Audio working in car - no controls for futify (doesn't stop playing when car shuts off - switches to phone audio)
    • Mic and speaker working in car
    • Headset (earbuds) working
  • Mobile Data
    • 3G Stable but slow
    • 4G
      • Initially thought not working - but issue is repeatable in 1 part of house (weak signal issue, ofono bugs??). When 4G started in area with good signal, seems pretty stable
    • APN settings: buggy: can edit but can't add (Maybe carrier specific)
  • SMS / MMS
    • SMS is stable and working
    • MMS Haven't tested - mostly using signal
    • Signal on Axotl - buggy (see bleow)
      • unlike android, doesn't converge all texts - so SMS are in one app, signal messages in another

• Background

  • Canada / Bell network

  • Daily Drive Needs:
    Telegram (Teleports Good but missing some features)
    Signal (Buggy due to recent Signal changes)
    Email (Dekko2 not working with our email server, using webapp but no push)
    Calendar (no - webapp workaround)
    Contacts (imported, but no sync)
    Matrix (fluffychat works well)
    Phone (stable)
    SMS (works - but not merged with Signal)
    MMS - (not tested)
    KeePassXC (Keepweb)
    NextCloud (using webapp)
    Notes Synced (using Carnet app inside NextCloud)
    Camera (working but slower and Quality/features not as good)
    Pictures autoupload - (need to investigate options)
    Spotify ( Futify - usable but qute far from feature parity, no spotify connect)
    Navigation / Maps (working but very slow due to GPS lock need)
    HomeAssistant (Webapp working great)
    Jitsi (using webclient: can see and hear, but no camera or mic input through Morph)
    News ((webapps working well)
    - NYT
    - CBC
    - Globe and Mail

    Nice to Have
    - Reddit (Quickddit OK)
    - Netflix casting (No)
    - Mastadon (Working: Umastonauts)
    - ...

@manland

Thanks so much for the great work! Been using the old version for a few months and was struggling with the download issue: Had to wait forever to get to songs at the bottom of long playlists. Switched to new one and will report back ... Thanks again!

@freefrog Hi, i am in Canada ... Which usually has pretty similar frequencies as usa.

My pixel 3a is running pretty well on 3g. (rough daily driver now for about a week).

Yes, you would need to enter apn info for both internet and mms. You can usually find this info online for your carrier. some apn settings are missing (at least for me. Eg: mmc) but sms and internet is working. Not sure about mms as most of my contacts are on signal.

I dont know of the proper repo/issues list to track the ofono problems...but ibwould be intwrested to know if find it ... Would obviously like to have 4g working.

@mellowmatt

No MMS here (think this is a bigger bug relating to lack of standards across carriers) ... but I do get SMS inbound. I had luck changing and saving the auto generated APNs. I was never able to create a new one - same problem as you - no reaction on clicking Check box: greys out then hangs without saving. By default, I had one APN for "MMS" created and one for "Internet". There doesn't appear to be any place for some of the other settings from Android like MMC, etc.

One thought might be to track down where these setting are stored and modify / create new ones from the terminal ... although not sure if that is possible.

One other thought: be sure you get a true reboot after making these changes - for me, first reboot attempt restart GUI, second ususally works. Need to do 3 to get a true power off.

Good luck and update us if you figure something out!

@3t_ed If you enable USB debugging, next time it happens, you can plug into a computer (with adb tools) and run adb shell. This will bring up a terminal: run "Top" then hit "m" twice to see memory and swap % use.

So I built a routine that allowed me to reproduce the lockups (where the swap use shown in top (zram) hits 100%, and memory is 95+% used) - it basically involves opening a bunch of webapps / apps that I use; but all at once in fast sequence. The camera is one app that needs a bunch of memory ... and can easily push the device over the edge).

I then tweaked memory control parameters as per various suggestions found online and repeated the test. I was able to get a lot further before lockup with the settings below. (The phone uses less zram as I progress through my test, I guess ultimately pushing back the time to lockup). I haven't noticed any performance hit (purely subjective), and I can run many days now without lockup. On the one occasion where I did lockup, recovery was faster (rather than 1-3 mins, it was ~10 seconds)l; however I did notice one of my open apps was killed (white page with green triangle saying refresh). Haven't figured out how to set this across boots - although my reboots are a lot less frequent!

Disclaimer: This is for the pixel3a - that has 4GB of RAM and ~ 1.6GB zram setup. Based on my reading, I think some of these settings are very specific towards hardware (memory, cpu, swap vs. zram) on the device... also, I am a hack wrt linux and have NO other experience with these settings:)

sudo sysctl vm.min_free_kbytes=29620 &&
sudo sysctl vm.vfs_cache_pressure=200 &&
sudo sysctl vm.dirty_background_ratio=3 &&
sudo sysctl vm.dirty_ratio=40 &&
sudo sysctl vm.admin_reserve_kbytes=16384 &&
sudo sysctl vm.swappiness=80

Hope this helps ...

@3t_ed To elaborate a bit further: First, Alfred applied those changes to the port. One OR 2 did not stick properly and rather than chasing down the issue further, he remove zram completely. So the dev version of p3a is no longer using any swap. There are no more lockups, but (IMHO) there is a little less bandwidth for multitasking, especially after a few days of uptime (where presumably software memory leaks have chewed into the avail 4GB of ram. All in all a big improvement ... would be good if some other could test and chime in their thoughts.

https://github.com/fredldotme/android_device_google_bonito/commit/cea569eb00838ad9cb6e16471b69510b0f0e0e47

https://github.com/fredldotme/android_device_google_bonito/commit/f4df3991231cf4f7aab62584a9289a7642b88e9c

@ultrasonicnoise

Hmm ... so if that APN is no longer in the file, then maybe it is not matching the "3" in the name field and so it defaults to what the provider or sim card sets? (I am assuming that is what it uses to match ... ) Sorry, not sure what to suggest from here ... ??

  <provider primary="true">
                <name>3</name>
                <gsm>
                        <network-id mcc="234" mnc="20"/>
                        <apn value="three.co.uk">
                                <usage type="internet"/>
                                <name>3 Internet</name>
                        </apn>
                        <apn value="3internet">
                                <plan type="postpaid"/>
                                <usage type="internet"/>
                                <name>Internet</name>
                        </apn>
                        <apn value="three.co.uk">
                                <usage type="mms"/>
                                <name>3 MMS</name>
                                <mmsc>http://mms.um.three.co.uk:10021/mmsc</mmsc>
                                <mmsproxy>217.171.129.2:8799</mmsproxy> <!-- mms.three.co.uk -->
                        </apn>
                </gsm>
        </provider>

In my past experience (and more recently on a fresh 20.04 install), sometimes the UI is glitchy to accept and remember changes (you did reboot, right?) ... To overcome this, I had luck changing the file that feeds the default APN settings when you reset / delete them then reboot. The file is:

/usr/share/mobile-broadband-provider-info/serviceproviders.xml

To edit it, you will need to remount the / file system r/w ...

I found my carrier ... then edited the section to reflect the proper APN entries ... then delete APN entries & reset (they were hard to get rid of) then reboot ... and it should pull in the new values from that file. Hope this helps!

Thanks for the write up!

I have been running with this setup for a while. Couple of other things to point out (maybe there are solutions I've missed?):

I can not get images/pictures in encrypted chats: Just shows a cloud with an exclamation point in it. On UN-encrypted chats, the images come in fine.

"Spaces" are not handled properly - they show up as chats/rooms with no real content in them.

Perhaps obvious, but worth to point out that calls don't work (voice nor video) ... although I think it rings.

@3t_ed To elaborate a bit further: First, Alfred applied those changes to the port. One OR 2 did not stick properly and rather than chasing down the issue further, he remove zram completely. So the dev version of p3a is no longer using any swap. There are no more lockups, but (IMHO) there is a little less bandwidth for multitasking, especially after a few days of uptime (where presumably software memory leaks have chewed into the avail 4GB of ram. All in all a big improvement ... would be good if some other could test and chime in their thoughts.

https://github.com/fredldotme/android_device_google_bonito/commit/cea569eb00838ad9cb6e16471b69510b0f0e0e47

https://github.com/fredldotme/android_device_google_bonito/commit/f4df3991231cf4f7aab62584a9289a7642b88e9c

@rik @Fizz @jezek
Sorry guys ... don't check in here often. Yes, I am also experiencing the "Invalid URL" ...
I believe this is a nuntium bug and raised an issue here
The issue was also experienced by @notkit and there was a hint on where to look for the issue here
Since it is not happening to everyone, my current guess is that the parsing of the URL for those with a PROXY is breaking something: @fizz and I have proxy, don't think you or others do @rik? Either that or the port? (although since its :80 ... I have tried without it and had same results).

TLDR: try pda2.bell.ca for one of the APN's (Internet).

Full version:

On Bell Canada. WITHOUT the patch that allows merged apn entries, this should work (Although I have a bug in nuntium that prevents me from receiving ... I CAN wget the files so hopefully some version of these will help out):

[context1]
Name=Internet
AccessPointName=pda2.bell.ca
Username=
Password=
AuthenticationMethod=none
Type=internet
Protocol=ip
Preferred=true
MessageProxy=
MessageCenter=

[context2]
Name=bell mms
AccessPointName=pda.bell.ca
Username=
Password=
AuthenticationMethod=none
Type=mms
Protocol=ip
Preferred=true
MessageProxy=web.wireless.bell.ca:80
MessageCenter=http://mms.bell.ca/mms/wapenc

To make this stick through APN resets I changed the bell section of my /usr/share/mobile-broadband-provider-info/serviceproviders.xml

        <provider>
                <name>Bell Mobility</name>
                <gsm>
                        <network-id mcc="302" mnc="610"/>
                        <network-id mcc="302" mnc="640"/>
                        <network-id mcc="302" mnc="651"/>
                        <network-id mcc="302" mnc="880"/>
                        <apn value="pda2.bell.ca">
                                <plan type="postpaid"/>
                                <usage type="internet"/>
                                <name>Internet</name>
                        </apn>
                        <apn value="pda.bell.ca">
                                <plan type="postpaid"/>
                                <usage type="internet"/>
                                <name>Mobile Web</name>
                        </apn>
                        <apn value="pda.bell.ca">
                                <usage type="mms"/>
                                <name>bell mms</name>
                                <username></username>
                                <password></password>
                                <mmsc>http://mms.bell.ca/mms/wapenc</mmsc>
                                <mmsproxy>web.wireless.bell.ca:80</mmsproxy>
                        </apn>
                        <apn value="pda2.bell.ca">
                                <plan type="postpaid"/>
                                <usage type="internet"/>
                                <name>Mobile Fast Web</name>
                        </apn>
                </gsm>

So I built a routine that allowed me to reproduce the lockups (where the swap use shown in top (zram) hits 100%, and memory is 95+% used) - it basically involves opening a bunch of webapps / apps that I use; but all at once in fast sequence. The camera is one app that needs a bunch of memory ... and can easily push the device over the edge).

I then tweaked memory control parameters as per various suggestions found online and repeated the test. I was able to get a lot further before lockup with the settings below. (The phone uses less zram as I progress through my test, I guess ultimately pushing back the time to lockup). I haven't noticed any performance hit (purely subjective), and I can run many days now without lockup. On the one occasion where I did lockup, recovery was faster (rather than 1-3 mins, it was ~10 seconds)l; however I did notice one of my open apps was killed (white page with green triangle saying refresh). Haven't figured out how to set this across boots - although my reboots are a lot less frequent!

Disclaimer: This is for the pixel3a - that has 4GB of RAM and ~ 1.6GB zram setup. Based on my reading, I think some of these settings are very specific towards hardware (memory, cpu, swap vs. zram) on the device... also, I am a hack wrt linux and have NO other experience with these settings:)

sudo sysctl vm.min_free_kbytes=29620 &&
sudo sysctl vm.vfs_cache_pressure=200 &&
sudo sysctl vm.dirty_background_ratio=3 &&
sudo sysctl vm.dirty_ratio=40 &&
sudo sysctl vm.admin_reserve_kbytes=16384 &&
sudo sysctl vm.swappiness=80

Hope this helps ...

So turns out the swap showing on our Pixel3's is ZRam (Fake swap on memory that is compressed). The 100 setting is appropriate for this setup. Will keep digging around for some way to prevent 100% use ... (which is the source of my lockups).

A bit too quick to declare success ... I locked up with 100% swap usage again today while my swappiness was set to 20. Still think it is a beneficial change for the life of the emmc ... however, issue persists.
@domubpkm ... Not sure yet how to persist this across reboots ... going to reach out to porters to see where this setting is established.

One further update:

sudo cat /proc/sys/vm/swappiness returns 100 ...

Is this parameter used in UT? If so, that doesn't make sense.

The default value of vm.swappiness is 60 and represents the percentage of the free memory before activating swap. The lower the value, the less swapping is used and the more memory pages are kept in physical memory.

I set mine to 20 ... and my test of opening a ton of webapps starts using swap much later.... and I haven't hit lockup yet. Not sure how to persist it though...

sudo mount -o remount,rw /
sudo sysctl vm.swappiness=20