The connection of CustomTabsCallback may be lost while Custom Tabs App is in background.
Reported by
yam...@bsdhouse.org,
Dec 6 2016
|
|||
Issue descriptionApplication Version (from "Chrome Settings > About Chrome"): 54.0.2840.85 Android Build Number (from "Android Settings > About Phone/Tablet"): NMF26F (Android 7.1.1) Device: Nexus 6P Steps to reproduce: 1. Check out https://github.com/GoogleChrome/custom-tabs-client 2. Build and install the example app in custom-tabs-client/Application/. 3. Launch the app. 4. Tap "Connect to the service" -> "Launch URL in a Chrome Custom Tab". 5. Confirm that messages like "CustomTabsClientExample: onNavigationEvent: Code = x" are logged in the ADB logcat. 6. Tap device's Home button. 7. Open "Settings" -> "Developer options". 8. Change "Background process limit" to "At most 1 process" or "No background processes". 9. (At this time, the example app's process should be killed.) 10. Revert "Background process limit" to "Standard limit". 11. Tap device's Recent button, and select the "Chrome Custom Tabs Example" app. 12. Click some links in the Custom Tab. Observed behavior: "onNavigationEvent" messages are no longer output in the logcat. Expected behavior: The example app's process will be relaunched, and it handles the navigation events. Frequency: always Additional comments: In the above steps, I used "Developer options" to kill the background process explicitly, but it happens often while apps are in background. So, if the background processes were killed, we should restore the connection of CustomTabsCallback when the Custom Tab is back to the front. (In this case, KeepAliveService is useless because the Custom Tab Activity is stopped.) I think CustomTabsCallback should be implemented using PendingIntents or a bound Service.
,
Dec 12 2016
,
Dec 15 2016
Hi, Thanks for the feedback. This is indeed the current behavior, but I'm not entirely sure that's something that we should change. One of the initial motivation was to make Custom Tabs as easy as possible to use from an application, without imposing requirements on the app. Adding a bound service on the app side is going the other direction. Is this an issue that you're hitting in your app? If so, can you be more specific about the use case you have?
,
Dec 15 2016
Thanks for your reply. > Is this an issue that you're hitting in your app? If so, can you be more specific about the use case you have? To be honest, I'm concerned about postMessage API rather than onNavigationEvent. https://codereview.chromium.org/2438103002 https://bugs.chromium.org/p/chromium/issues/detail?id=581345 I'm eager to have this API for our app! However, the current implementation doesn't reconnect the session when the app was killed. So, I think it becomes a big problem for out product. I'm thinking that the postMessage callback should be implemented using a bound service like android.widget.RemoteViewsService. What do you think?
,
Dec 21 2016
yamasa@, we are in the process of updating postMessage API to have a bound service for website to client app communication. I think this will address your concerns around lifecycle issues. If that was the main concern, please feel free to mark this issue fixed.
,
Dec 22 2016
Hi, > yamasa@, we are in the process of updating postMessage API to have a bound service for website to client app communication. I think this will address your concerns around lifecycle issues. Great!! > If that was the main concern, please feel free to mark this issue fixed. Yes, that's the main concern. So, feel free to close this issue. I'm looking forward to using postMessage API. Thank you!
,
Jan 3 2017
|
|||
►
Sign in to add a comment |
|||
Comment 1 by candr...@chromium.org
, Dec 12 2016