問題描述
谷歌cast MediaNotificationService 中的大量RemoteServiceExceptions (Large number of RemoteServiceExceptions in Google's cast MediaNotificationService)
在過去約 24 小時內,我們在 Google 的 MediaNotificationService
中看到了數千次崩潰:
Fatal Exception: android.app.RemoteServiceException
Context.startForegroundService() did not then call Service.startForeground(): ServiceRecord{f9a4deb u0 <our package name>/com.google.android.gms.cast.framework.media.MediaNotificationService}
android.app.ActivityThread$H.handleMessage (ActivityThread.java:1855)
android.os.Handler.dispatchMessage (Handler.java:106)
android.os.Looper.loop (Looper.java:214)
android.app.ActivityThread.main (ActivityThread.java:6986)
java.lang.reflect.Method.invoke (Method.java)
com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:494)
com.android.internal.os.ZygoteInit.main (ZygoteInit.java:1445)
我在創建自己的前台服務時遇到了類似的問題,但由於這是在演員庫中,我們無法控制它。
Chromecast 接收器由第三方處理。我們正在使用:
api "com.google.android.gms:play‑services‑cast:17.0.0"
api "com.google.android.gms:play‑services‑cast‑framework:17.0.0"
潛在線索:
- 它正在發生在 OnePlus、華為、三星、谷歌,似乎每個製造商(和操作系統水平)的數字與其市場份額相關。
- 崩潰發生在不同設備的不同線路上(例如,上面是 Galaxy S9,而 S8 在 1872 線路上崩潰),所以在 Crashlytics 上沒有組合在一起。這表明這是一個操作系統/Google Play 服務級別的問題。
- 崩潰發生在應用程序的所有活動版本中,同時開始。
- 崩潰一直在發生數月以來數量很少,但在周末突然飆升,並且沒有放緩的跡象。
更新:終於設法重現了這一點。在屏幕鎖定的情況下長時間投射內容,然後與設備斷開連接時,會發生崩潰。或許離解決方案又近了一步……
li>幾個月來,崩潰的發生率一直很低,但在周末突然飆升,而且沒有放緩的跡象。更新:終於設法重現這個。在屏幕鎖定的情況下長時間投射內容,然後與設備斷開連接時,會發生崩潰。或許離解決方案又近了一步……
li>幾個月來,崩潰的發生率一直很低,但在周末突然飆升,而且沒有放緩的跡象。更新:終於設法重現這個。在屏幕鎖定的情況下長時間投射內容,然後與設備斷開連接時,會發生崩潰。或許離解決方案又近了一步……
參考解法
方法 1:
It looks like a known issue:
Issue occured only on HUAWEI devices with Android 9 : P20 pro, P30 pro, P20 lite, P30, P20, Honor View 10, Mate 20 pro
Cast SDK version : Android Sender 16.2.0 (I checked release notes of Android Sender 17.1.0 but no bug fixes)
Here is the crash log from fabric :
Fatal Exception: android.app.RemoteServiceException: Context.startForegroundService() did not then call Service.startForeground(): ServiceRecord{3ac0035 u0 com.google.android.gms.cast.framework.media.MediaNotificationService}
at android.app.ActivityThread$H.handleMessage + 2126(ActivityThread.java:2126)
at android.os.Handler.dispatchMessage + 112(Handler.java:112)
at android.os.Looper.loop + 216(Looper.java:216)
at android.app.ActivityThread.main + 7625(ActivityThread.java:7625)
at java.lang.reflect.Method.invoke(Method.java)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run + 524(RuntimeInit.java:524)
at com.android.internal.os.ZygoteInit.main + 987(ZygoteInit.java:987)
that a Google engineer says is fixed:
We have a fix for this and that should be released by the next Android Cast client library release.
but they don't know when the fix will be released:
So far we don't have a solid date when the next release will be scheduled. We will update it here or else please do check here https://developers.google.com/cast/docs/release‑notes
The release notes don't mention a fix for this.
I'll update this answer if I find anything further.
Update
This is fixed. See Anjaneesh
's answer.
Update
There are some issues with 18.0.0
. See rednaz
's answer. Also, commenters on the issue are still experiencing crashes with Samsung and Huawei platforms, but at greatly decreased rates. I filed a new issue about this.
方法 2:
The fix has been released on the Android Cast SDK client library v18.0.0 (check the second item of the release notes: https://developers.google.com/cast/docs/release‑notes#december‑5,‑2019)
The crash should be fixed once you update to v18.0.0
方法 3:
We are also experiencing this issue with very similar symptoms. We are on cast SDK version 16.1.2
- Only happening on Android 8 and above. Seems to be linked to the background execution changes here
- Also low numbers for months. Spiked recently across all app versions. Now looking at numbers in the thousands.
- There was a play services update on 11th Feb. Could be linked?
</ul>
What we've tried (Updating to SDK 18.0.0)
Updating to v18.0.0 appears to fix the issue as reported by @Anjaneesh. However, 18.0.0 introduced behaviour changes around the retrieval of custom data. We have observed that the custom data we supply to the remoteMediaClient's mediaInfo (and then try to retrieve) gets nulled when the sender app disconnects and then re‑connects. This will need guarding against if you aren't already!
(by Jake Lee、Heath Borders、Anjaneesh Rayapati、rednaz)