Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Notification received while app is running kills the app #853

Closed
JueBag opened this issue Apr 21, 2018 · 13 comments · Fixed by #855
Closed

Notification received while app is running kills the app #853

JueBag opened this issue Apr 21, 2018 · 13 comments · Fixed by #855
Labels
bug Indicates an unexpected problem or unintended behavior

Comments

@JueBag
Copy link

JueBag commented Apr 21, 2018

Just tested the restarted notification service and found a problem.
If the app is running in background while the message is received followed by the message clicked OK, the app gets either stopped or a selection window gets displayed asking for stopping the app or giving fedback (checking on two different android devices)

App Version 2.1.0

@maniac103
Copy link
Contributor

Can you please show a screenshot of what you mean by 'the message clicked OK'? Thanks.

@mueller-ma mueller-ma added the bug Indicates an unexpected problem or unintended behavior label Apr 22, 2018
@JueBag
Copy link
Author

JueBag commented Apr 22, 2018

stopped
message
Selecting the received message from the second picture results in the displayed message in the first picture.
This message made me think that the app was stopped, however it seems to remain working. Sorry for that "false" report, however I think the displayed message telling that the app is stopped shouldn't come up.

@maniac103
Copy link
Contributor

maniac103 commented Apr 22, 2018

Indeed, it shouldn't come up. You can't collect logcat after that incidence by chance, can you?
@mueller-ma Is there any ANR report in the Play Store console?

Edit: thinking about it, 'Angehalten' likely is a crash. What Android version is this? And I assume the notification was created by sending a test message from the web page in the background and not by OpenHAB itself?

@mueller-ma
Copy link
Member

@JueBag Which device and Android version do you use?

@maniac103 There is only one ANR for the 2.1.0 version:

Input dispatching timed out (Waiting to send non-key event because the touched window has not finished processing certain input events that were delivered to it over 500.0ms ago. Wait queue length: 92. Wait queue head age: 860185.5ms.)

There are a lot of stacktraces show for this anr, but none of them contain lines about the org.openhab.habdroid package.

@maniac103
Copy link
Contributor

@mueller-ma May I get read-only access to the Play Store console so I can check the crashes myself? If yes, how can I non-publically tell you my Gmail address?

@JueBag
Copy link
Author

JueBag commented Apr 22, 2018

Yes I was sending the messages from the myopenhab page. Used it from one device to the other.
The devices used are a Samsung A3 phone (Android7.0) and a Samsung Tab4 (standby on Android version)
Never used LogCat, let me see what I can do.

@JueBag
Copy link
Author

JueBag commented Apr 22, 2018

Got LogCat, recorded while sending a message from the webpage. However I can't see anything in that log, except maybe an entry "Input channel destroyed" (but I'm new to this.)

@mueller-ma
Copy link
Member

May I get read-only access to the Play Store console so I can check the crashes myself? If yes, how can I non-publically tell you my Gmail address?

While it makes sense to give you access to stacktraces, @kaikreuzer needs to decide that.

@maniac103
Copy link
Contributor

You likely captured logcat via non-root app (be it a terminal emulator or something like MatLog). In that case, the captured log only contains log line of that app. You'll need either root or capture via 'adb logcat' on a PC.

@JueBag
Copy link
Author

JueBag commented Apr 22, 2018

Yes, my devices are not rooted. Since I'm away from my PC (Scotland atm) I can't help on that topic. Sorry

@maniac103
Copy link
Contributor

I can reproduce, so never mind :-) I've seen that particular issue before, and thought I fixed it at some point, but the fix probably got lost during rebasing or in some refactor. I'll fix it.

@maniac103
Copy link
Contributor

9c683b2 is the commit I thought of. It didn't get lost, but is not sufficient either: it should check for 'cloud connection present && started' before opening the notifications pane.

maniac103 added a commit to maniac103/openhab.android that referenced this issue Apr 23, 2018
PR openhab#789 attempted to fix this already, but was incomplete: if a
notification was clicked and the cloud connection already was resolved
at the time the activity was created (which may or may not have
happened, as activity creation in main thread and cloud connection
resolving in update thread race against each other), fragment updates
happened even though the activity wasn't started yet. Fix this by
tracking explicitly whether the activity is started, and deferring
updates until then.

Closes openhab#853

Signed-off-by: Danny Baumann <dannybaumann@web.de>
mueller-ma pushed a commit that referenced this issue Apr 23, 2018
…855)

PR #789 attempted to fix this already, but was incomplete: if a
notification was clicked and the cloud connection already was resolved
at the time the activity was created (which may or may not have
happened, as activity creation in main thread and cloud connection
resolving in update thread race against each other), fragment updates
happened even though the activity wasn't started yet. Fix this by
tracking explicitly whether the activity is started, and deferring
updates until then.

Closes #853

Signed-off-by: Danny Baumann <dannybaumann@web.de>
@mueller-ma
Copy link
Member

@maniac103 You should have received a mail from me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Indicates an unexpected problem or unintended behavior
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants