Tested the issue on android and unable to reproduce this issue

Steps to reproduce:
--------------------------
1. Launched chrome, navigated to https://epoh.ng , added to homescreen
2. Closed browser, launched app from homescreen, played audio and switched to different app -- app is not killed even after 20-30 mins

Chrome version:
70.0.3538.17

OS:
Android 8.0 

Android device:
Pixel 

@chimezie: Please check the above steps and let us know if we miss anything. Is this issue consistently reproducible? Could you please let us know the device on which you are seeing this issue? Any information on reproducing the issue would help in better triaging.

Thanks!

I'm on OnePlus 5T, I have gotten the complain from other people as well and I have been able to reproduce on Samsung Note as well.

Also, these is Stackoverflow link https://stackoverflow.com/questions/38907239/prevent-android-from-closing-a-progressive-web-app-playing-audio-in-the-backgrou/52371490#52371490

I will try over and over and see what more information I can offer.

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Attaching a video, not sure how much that would help

Deleted: 2018_09_17_11_10_08.mp4 8.2 MB

	2018_09_17_11_10_08.mp4 8.2 MB View Download

Most of the video attached in comment#5 is black. Could you please add another video which is clear and also provide bug report for above scenario. This would help in further triaging.

Thanks!

The black screen was as a result of me turning off the screen my phone screen. I can try without locking the phone if you prefer.

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

+Mounir/Bo. 
We have special treatments for renderers that are playing music in background to try and keep them high priority. I suspect some of our WebApk machinery doesn't offer the same behaviour

chimezie@epohcj.com: does the same behaviour happen when you run the pwa from within a tab in chrome?

I have not noticed it within chrome tab but will run some tests to confirm

content layer isn't aware of webapk at all at this point I believe, so there shouldn't be any difference between webapk and a normal chrome tab.

Which chrome version and which channel are you using? 70 can't be stable yet. I am interested in seeing experiments that are enabled in the chrome instance where this reproduces. Can you go to chrome://version and paste save and attach the whole page here.

Oh, also if you don't mind publishing the log information from the device, having the entire logcat during the repro helps too.

#12: I'm just wondering if content ever asks a delegate about UI visibility or something and ChromeTabbedActivity handles it specially where WebApkActivity is more naive. Could be entirely wrong though. I agree that logs would be helpful

It doesn't depend on the activity. content internally tracks which frame is playing media, and just raises the priority of the process hosting that frame. It doesn't depend on anything from the activity.

Where it breaks down is with site isolation, and the frame playing media is not the main frame. We only raise the priority of the subframe, which means any of its ancestor frames are still likely to reclaimed, bringing down the whole subframe tree. Hence knowing if site isolation is enabled by an experiment is relevant.

This is the chrome://version info

Deleted: chrome.version 2.2 KB

chrome.version 2.2 KB Download

you are on the beta channel. we are not yet experimenting with site isolation on beta channel yet and chrome://version confirms this, so that can't be the explanation

the log

BTW this is on chrome tab so it seems it not restricted to homescreen instance

Deleted: pwa-music.log 3.0 MB

pwa-music.log 3.0 MB View Download

From the logs, I think it's pid 22732 that's the renderer that's playing media. It died like this:
09-18 14:11:32.040  1283  3825 I ActivityManager: Process com.chrome.beta:sandboxed_process3 (pid 22732) has died: cch  CACC

However, right before AM killed the process, this happened:
09-18 14:11:31.932 22015 26635 W cr_MediaCodecBridge: Releasing: OMX.qcom.video.decoder.avc
09-18 14:11:31.952   952  1134 I OMX-VDEC-1080P: omx_vdec::component_deinit() complete
09-18 14:11:31.955   952  1134 I OMX-VDEC-1080P: Exit OMX vdec Destructor: fd=11
09-18 14:11:31.955   952  1134 I OMX-VDEC-1080P: Video slvp perflock released
09-18 14:11:31.957 22015 26637 D SurfaceUtils: disconnecting from surface 0xe5858008, reason disconnectFromSurface
09-18 14:11:31.960 22015 26635 W cr_MediaCodecBridge: Codec released
09-18 14:11:32.005  1283  2433 I MediaFocusControl: abandonAudioFocus() from uid/pid 10308/21776 clientId=android.media.AudioManager@999ccd0org.chromium.content.browser.AudioFocusDelegate@bc3c4c9

Also cch means > CACHED_APP_MIN_ADJ. CACC means PROCESS_STATE_CACHED_ACTIVITY_CLIENT

I'm not entirely sure what the state of browser is. But looks like media finished playing, the renderer was dropped to cache level (is waived binding), then android just killed it. Nothing out of the ordinary? Is that what happened?

just to confirm, the renderer is not the browser right? Because with you go back the app is gone....or in the case of the chrome tab, the page is reloaded

Background here: https://www.chromium.org/developers/design-documents/multi-process-architecture

Renderer is generally a single tab, or in the case of pwa, then entire pwa. If android kills a renderer, then going back to that tab/pwa will cause a reload. If android kills the browser process (ie chrome app process), then re-opening chrome or the pwa will also cause a whole reload, but slower. It might be difficult to distinguish these two visually.

Apps has the ability to hint to android that certain processes are important, so it should kill other less important processes first. When chrome is playing music in the background, the browser process is protected by the foreground notification, and the renderer is protected by the browser process.

What I was trying to say in #19 is that the protection went away first, and then android went ahead and killed the renderer to free memory. So that's more or less working as expected. The thing to work out is why did that protection go away.

Maybe this happens when switching between songs in the pwa? If protection is dropped when going to a new song, then I guess that could explain this. Purely speculating at this point though.

I would bet for sure I have seen it killed mid-way while a song is playing. 

Though I might know the answer already,  but from a user's perspective even if it is killed between song transition.....why doesn't same pwa/tab if the song was not playing.....because the app itself can sit there all day without being killed?

I don't understand your question

Note hinting to android that a process is just a hint. Android should kill less important processes first. But if the current foreground process requires so much memory that there is nothing less important than chrome, then android will kill chrome to free memory as well.

Your point is that the app/tab was killed because the song is done playing (lost its protection) and that is fine ....but the same app/tab will not be killed if I had not played any song at all.

No. Playing media means android is more likely to keep those processes alive. If it's not playing media, then chrome or the tab is likely to be killed a long time ago.

But it seems like it is targeting tabs/apps that play(ed) music...because I can open this app all day and it will not be killed until I start playing some song

Any more efforts towards reproducing this or what other information I can give to help understand more what is going on here?

The currently foreground app is the most important process. If you always keep chrome foreground, then it should (in theory) run forever.

I don't see anyone on our side actually trying to reproduce the issue..

The app could be running in the background and will be killed.

The use-case that is really a problem is a use opens the app, starts playing a song. Most of the time, you will switch apps and/or put your phone on standby to enjoy the music. This app will not go through the whole playlist and it gets killed.

This is a very bad user experience.

Please let me know what else you guys need from me and I will to see if I can find more pattern here

Thanks

another log. This time I can confirm the song was still playing when the app was killed

Deleted: 20180919-212522_oemlog.zip 10.9 MB

20180919-212522_oemlog.zip 10.9 MB Download

I don't know that well the nasty details of Android but, boliu@, is it possible that the foreground service would apply to Chrome instead of the Web APK?

Android's oom killer works at the process level, so it's the same browser process regardless of whether it's a webapk or a tab in chrome.

Tested the issue on android and able to reproduce this issue

Steps to reproduce:
--------------------------
1. Launched chrome, navigated to https://epoh.ng , added to homescreen
2. Closed browser, launched app from homescreen, played audio and switched to different app, after completion of 1 song, notification icon closes and 2nd song doesn't play

Chrome version:
70.0.3538.17 , 70.0.3538.27 , 71.0.3557.2

OS:
Android 7.0 

Android device:
Samsung s7

NOTE: Tested this issue on different versions
Good Builds: 64.0.3242.0 ,67.0.3396.87 ,68.0.3399.0, 68.0.3423.0, 
Bad Builds: 70.0.3503.0 , 70.0.3517.0, 70.0.3538.27

Unable to bisect as we are unable to add site to home screen on installing builds between above builds, seeing "Adding to homescreen..." message is seen and after sometime notification is lost and isn't added.

NOTE:
1. On previous beta 69.0.3497.86 issue is good, after completion of 1st song after few seconds 2nd song played automatically
2. On current beta 70.0.3538.27 after 1st song, notification is lost and no song is played.

Hence considering this as Non-Regression and marking as Untriaged. Please feel free to change if this is not the case.

Thanks!

What's generally the timeline for this triage to happen....or I guess what is next step for this?

I'm using chrome beta 70.0.3538.32 on a samsung s7, and I still can't reproduce this. Test can reproduce it though, so not sure how to reconcile this. +satyavathir: can someone in the office try reproducing this, and hand me the device if yes.

any updates?

We will try and update the bug tmrw.
Thanks! 

Unable to repro the issue mentioned on Nexus 6P/OPM1.180608.001 having latest 71.0.3578.31(Beta) and 70.0.3538.80 (stable release) and step followed :
1. Launched chrome, navigated to https://epoh.ng , added to homescreen
2. Closed browser, launched app from homescreen, played audio and switched to different app like pinterest , feedly ,Amazon shopping did scroll action and read many articles by tapping back button ,and tried accessing the different apps for 15-20 minutes 
3.Observed next song from the list continued to play on multiple times on Different song list from epoch.ng .
Unable to repro the issue mentioned in comment #0

Just to confirm, the time is abitrary. If we can give it a bit more time.

Try this also;
After switching to a different app, put the phone is standby mode (turning off the screen) as seen in the video and let the song continue to play in the background

Thanks.

I can still reproduce this issue.

September, October, November, December.....and no concrete action item on this.

If reproducing this is the issue, how else can I support the dev test to do so.....and since QA can reproduce I thought you guys can take it from there?

Bo: can you try and confirm/deny whether this is bindings related?

Another thought might be is that if the app is performing a navigation while in background - maybe policies are different?

> Bo: can you try and confirm/deny whether this is bindings related?

No I can't.

No one in the local office can reproduce this

sbashyam: can you try a Samsung s7? See #35

This issue has an owner, a component and a priority, but is still listed as untriaged or unconfirmed. By definition, this bug is triaged. Changing status to "assigned". Please reach out to me if you disagree with how I've done this.

Of note, I have this behavior happen regularly as well with my own PWA (https://subfiresuite.com/base).

It appears to be a pretty low-level Chromium-Android pattern, because it has also happened when the screensaver kicks in on an Amazon FireTV while my app is running in their WebView.  When the screensaver kicks in, it might finish the song that is playing...but then the next song won't start.