debug-20220623_231204.zip (24.2 KB)
debug-20220623_221743.zip (7.9 KB)
Ok so it’s not crash it’s the OS that kills the app:
Previous exit reason: 3/125 - null [2022-06-23 22:17:17.463]
From a few reports I have there’s a bug on Pixels on some devices and removing the updates of the Google app fixes this.
Is your Pixel a Verizon or AT&T version?
Hi Tolriq, thanks for the quick reply.
I’m in Australia, and the phone is not locked to any network. In fact, it doesn’t even have a SIM card any more.
I find it surprising that the OS would kill an app in the middle of it playing music. I have never seen any other music apps being killed in that way. Many other apps on that phone can play for hours without even needing any extra settings.
Also, if the OS kills an app, wouldn’t it give it a chance to save it’s current state, in this case it’s ‘Now Playing’ list and current song in that list so it can be restored on the next run.
The logs don’t lie 
and yes it’s surprising / should not be possible and it’s only some pixels, you can gather an OS bug report and check for yourself.
3/125
/**
* Application process was killed by the system low memory killer, meaning the system was
* under memory pressure at the time of kill.
*
* <p class="note">
* Not all devices support reporting {@link #REASON_LOW_MEMORY}; on a device with no such
* support, when a process is killed due to memory pressure, the {@link #getReason} will return
* {@link #REASON_SIGNALED} and {@link #getStatus} will return
* the value {@link android.system.OsConstants#SIGKILL}.
*
* Application should use {@link android.app.ActivityManager#isLowMemoryKillReportSupported()
* ActivityManager.isLowMemoryKillReportSupported()} to check
* if the device supports reporting {@link #REASON_LOW_MEMORY} or not.
* </p>
*/
public static final int REASON_LOW_MEMORY = 3;
/**
* Constant for {@link #importance}: This process is running a foreground
* service, for example to perform music playback even while the user is
* not immediately in the app. This generally indicates that the process
* is doing something the user actively cares about.
*/
public static final int IMPORTANCE_FOREGROUND_SERVICE = 125;
Symfonium does not keep the state when killed for the moment see quite a few posts here about the reasons.
Anyway I can’t reproduce on my Pixel 3a or Pixel 6 but there was quite a few investigations with 2 users, the issue seems to be related to some updates of Google app and bluetooth on some pixels . Removing the Google app updates fixed it for both of them.
I have no idea what bug Google introduced but until I’m able to reproduce I can’t workaround it properly.
Disabling media session seems to fix it but would cripple / kill some functionality.
Ok, as a software developer myself, I understand it is hard to fix something you can’t reproduce. It is unfortunate that your great app should suffer from such a crippling bug.
I am not clear what you mean by ‘disabling media session’. Is this something I can do on the phone, or you would need to change the app? If former, I am happy to try it.
Also, can you be more specific about the Google app. How and which Google app updates I need to remove?
I intend to use this Pixel 3 almost exclusively for playing music, and am willing to remove almost every other app.
About Media Session it’s something to remove in the app. Will prepare an APK with it disabled to test.
FYI my Google app version is the same (11.43.4.23.arm64). I have cleared it’s cache so let’s see if it helped. Give me an hour to test.
In all cases here’s an APK with an advanced settings to disable Media Session usage (near the end).
Requires force stop of the app to fully disable.
app-beta-final.apk (5.6 MB)
So far so good! I have managed to get through two Albums so far without a crash. Apologies, for calling it so, but from an user perspective it is a crash, whether it is caused by the OS or by a bug. The only thing I changed is clearing the Google app cache. I’ll keep it playing for a while longer before switching to the APK.
Also, given your fantastic responses so far, I have decided to pay for the full app. Will do that in the next couple of hours.
Yes I know users don’t see the internals and understand the numerous bugs OEMS generate in their roms (But for once this is really not a crash this is the OS killing the app from outside, it’s like telling that the TV have a bug when it’s switched off when you unplug the power cord). When you are the TV you have no power to prevent the unplug.
What’s more strange is that this occurs on Pixels and those usually respect Android principles 
But in the end more and more users start to understand that they can contact devs and provide logs, even if still a very low part this is better than a few years back.
Look, I agree with you to a large extent. But as I have said, there are many other music apps that do not suffer from this problem. So how would you see it if you were me.
But let’s not get into semantics. All good here. I had a problem, you helped me solved it (or at least it looks that way). I just bought the app. I hope that what I did may help you with the next customer who has the same or similar problem.
I don’t disagree I just document this particular issue The more users understand the difference the more users understand https://dontkillmyapp.com/ and the more pressure on the OEMs. (See Android Developers Blog: Developer-Powered CTS (CTS-D) Google start to also move on the right direction)
About other apps, there’s nearly no other app build targeting SDK 32 and fully embracing all the latest Android stuff and Android Auto and Compose …
For this particular issue it’s probably a bug on Google side with some very specific data that Symfonium passes on the Media Session (and others don’t) but without a device to reproduce it could takes months of random tries and sending users APK (Users who would give up early too :p)
For example on Yatse, Google have introduced a major bug on Pixels since March 2022 updates that crashed the app without reasons. Took me a ton of research to find a bug in AOSP that was here since a very long time, bug never reached by any OEMs. Bug that is triggered also because Yatse use advanced CharArrayBuffer to optimise things to their limits and that no other apps do. That does not mean that Yatse have a bug either, just that no other apps is optimized enough to trigger the OS bug
As a dev you know that another app reacting different does not mean anything for this kind of stuff.
But just to be clear I’m not arguing with you just push information for the others who will read this.
Understood. You are absolutely right. Other apps probably use different mechanisms to do achieve similar things. That must be the reason for all of this. I am sure in the long term it will work to your advantage - when Google fix their side, perhaps Symfonium will be a rare one that still works
And please do not spend any more time chasing this. We seem to have a work around. The app is still playing.
I still hope to figure out at least to report to Google like I did for the Yatse issue
There’s nothing that says that the issue won’t come back after some time when Google app cache is filled with whatever data triggers this.
Anyway you know that if it happens you can contact here to start a new round of debug
If by luck you know what ADB is and how to monitor logcat it will help.
And don’t forget to leave a rating on the Play Store it helps a lot for the start.
1 Like
Hi Tolriq,
unfortunately, I need to report bad news. Symfonium is still crashing on my phone.
After initial success with clearing the Google app cache, Symfonium played all night and then some without interruptions. However, it soon started crashing (ooops, began to stop playing in the middle of songs, and naturally losing the ‘now playing’ list).
I am now back to the situation where I was last week, I cannot listen to a few songs, or in other words, just listening to beginnings of albums
I have tried clearing the Google app cache repeatedly, without much effect. I have now paused the Google app, again without improvements. The only option I have left to try is the APK you posted earlier. I’ll try that later today.
Regards,
Dejan
Do not forget to check the option disable media session to actually test it.
1 Like
Hi Tolriq,
using the apk did not help. I still experience frequent crashes (every few songs).
However, I have tried a different thing now. Still early hours to make any conclusion but certainly indicative that I had my music playing for over an hour. So, most of the time in the past week, I have been directing output to my Onkyo amplifier (over bluetooth). Today I tried (both with standard app and the apk) listening via a Lenovo Smart Clock 2, without any noticeable difference. Then I tried my Bose Headphones, and… Voila, still playing.
Just to re-cap. The Google app is on pause, its cache is empty. Using the APK now (1.5.0B1(627)) Playing only local music via bluetooth. Pixel 3. And having noticeably different results when playing to Bose Headphones, comparing to other bt clients.
If it stops again, I’ll let you know immediately. Otherwise, let’s assume it is still playing. I’m happy to help in any way you think may be useful
Are you sure you enabled the option and restarted the app? Please provide logs to confirm it’s actually working as intended.
But this confirms the issue from the other users bug reports. Google have an issue with BT on those devices.
I suspected Google bt may be the culprit - you wouldn’t be doing bt yourself.
I cannot actually remember if I restarted the app after enabling the option. I think I did, but now that you ask, I am not that sure any more. Let me restart and try again. I’ll come back to you if it stops.
Four albums later, it is still playing. Most likely I did not restart the app after enabling the option. So far, it is encouraging, but I have been here before - I had the music playing the whole night, before it went back to stopping after a few songs. So, I’ll keep testing.