Skip to content
This repository has been archived by the owner on May 14, 2022. It is now read-only.

Wakelock doesn't work with Huawei + android 8.1 #262

Open
akumpu opened this issue Dec 11, 2019 · 23 comments
Open

Wakelock doesn't work with Huawei + android 8.1 #262

akumpu opened this issue Dec 11, 2019 · 23 comments

Comments

@akumpu
Copy link

akumpu commented Dec 11, 2019

Your Environment

  • Uploader Version Number: 0.7.1
  • Your Android Phone Model Name (e.g. Samsung J1 Ace): Huawei Honor 7s
  • Android Version Number (e.g. use 4.4 for 4.4.4): 8.1
  • Network Connection at the time the issue occurred (Wi-Fi, Mobile):Wi-Fi
  • (if relevant) Nightscout website version (e.g. 0.8.4 Funnel cake, master / dev branch):

Brief Explanation of Issue

Huawei's ash process hibernates uploader, i.e. its ignores acquired wakelocks

Uploader Error Code

CNL gives E86 and then USB connection is lost

Steps to Reproduce (for bugs)

The issue is permanent, and is visible after 5-10 mins from the start when CNL is connected to USB bus

The attached patch to AndroidManifest.xml seems to fix the issue
huawei.patch.gz

Don't know if it is a valid workaround/fix

Severity Score

5

@Pogman
Copy link
Collaborator

Pogman commented Dec 11, 2019

Thanks. Hopefully this is of use to some with this issue.

I had a look at the changes for possible inclusion but due to potential issues with security and variability across android versions and even products from the same manufacture and no real way to do broad tests, I think it will be up to the user to apply and build this patch for their device.

@steve8x8
Copy link

This doesn't explain why the same issue can be seen on a 7-year old tablet, running Android 4.4.4, constantly connected to wall power (it's got a separate charger socket - which was the main reason it's got a new job despite its age) and in devel settings there's "screen always on when on power". E86, nevertheless.
Some random message sent by the CNL seems to get in the way of normal query-read handshakes, and I suspect that ignoring that message (that doesn't start with the expected byte) and reading again might also address the issue.
There's python code that shows the same behaviour, and perhaps could more easily be tweaked to present the extra data - and get an idea of how to handle or ignore them. @ondrej1024 got closer to it - I'm out right now because I don't have access to the whole setup (which was given to a friend).

@Pogman
Copy link
Collaborator

Pogman commented Dec 11, 2019

@steve8x8 fyi the patch here addresses a particular device brand and their android customizations with manifest permissions.

Android 4.4.4 is really old and has it's own set of issues. While it's supported I would recommend using android versions from 6 on for solid reliability. Android OS will regularly kill apps and restart them without notification and when this happens while a CNL read is in progress it will E86. The android uploader has mitigations for this but with the older os it is much less reliable.

@akumpu
Copy link
Author

akumpu commented Dec 11, 2019

I was happy too early.
Next issue occured:
12-11 21:23:07.871 949 1181 I UsbAlsaManager: USB Audio Device Removed: null
12-11 21:23:07.878 949 1036 I UsbDeviceManager: HOST_STATE connected:false
12-11 21:23:07.880 1523 1761 I ash : android send broadcast:android.hardware.usb.action.USB_DEVICE_DETACHED notify package: info.nightscout.android, pid: 2983
12-11 21:23:07.880 1523 1761 I ash : info.nightscout.android { hibernation duration=204713 UptimeDuration=204714 } transition to: doze reason:bc_notify_android.hardware.usb.action.USB_DEVICE_DETACHED
12-11 21:23:07.932 2983 2983 D MasterService: receiver: android.hardware.usb.action.USB_DEVICE_DETACHED
12-11 21:23:07.944 1523 1761 I ash : android send broadcast:android.hardware.usb.action.USB_DEVICE_DETACHED notify package: com.android.gallery3d, pid: 5206
12-11 21:23:07.945 1523 1761 I ash : com.android.gallery3d { hibernation duration=730855 UptimeDuration=730856 } transition to: doze reason:bc_notify_android.hardware.usb.action.USB_DEVICE_DETACHED
12-11 21:23:07.989 12838 13637 E MedtronicCnlService: java.io.IOException: Error writing to usb endpoint
12-11 21:23:07.989 12838 13637 E MedtronicCnlService: at info.nightscout.android.USB.UsbHidDriver.write(UsbHidDriver.java:90)
12-11 21:23:08.011 1193 1193 D StatusBar: onNotificationPosted: StatusBarNotification(pkg=info.nightscout.android user=UserHandle{0} id=1 tag=null key=0|info.nightscout.android|1|null|10107: Notification(channel=error pri=2 contentView=null vibrate=null sound=null tick defaults=0x0 flags=0x0 color=0x00000000 vis=PRIVATE))
12-11 21:23:08.011 1193 1193 D StatusBar: addNotification key=0|info.nightscout.android|1|null|10107
12-11 21:23:08.038 1193 1193 D StatusBar: No peeking: not in use: 0|info.nightscout.android|1|null|10107
12-11 21:23:08.052 12838 13637 D UsbHidDriver: Releasing HID interface.
12-11 21:23:08.053 12838 13637 W UsbHidDriver: releaseInterface returned false
12-11 21:23:08.053 12838 13637 D UsbDeviceConnectionJNI: close
Any hints available to share :)

@akumpu
Copy link
Author

akumpu commented Dec 11, 2019

it seems that USB connection fails randomly, now-and-then. But it still works at next poll. So you can forget the previous message. Normal behaviour, perhaps?

@Pogman
Copy link
Collaborator

Pogman commented Dec 11, 2019

The usb device should never be issuing a detached broadcast unless it has actually become detached or the CNL self cuts the usb due to a E86 / E81 error (at around 10 mins after). Errors while in MedtronicCnlService would indicate this has happened during a poll. Are you absolutely sure the wired connection is solid?

@akumpu
Copy link
Author

akumpu commented Dec 11, 2019

It should be solid. CNL was "stationary" all the time on the table, and no one touched it. And USB connectors are tight ones.. Maybe I should try an another OTG cable?

@Pogman
Copy link
Collaborator

Pogman commented Dec 11, 2019

Sounds like it should be good if it's just sitting there. Keep tracking the logs for a while and maybe there is some underlying trend that will give a clue.

@akumpu
Copy link
Author

akumpu commented Dec 11, 2019

My daughter's CNL is several years old, so I don't know what kind of hits it got in those years :)
So it may CNL issue as well, bad connector or even connector is in loose from PCB side.
I'm planning to buy an another CNL for nightscout usage only.
I'll keep tracking it from the logs.. And I'll use IPA to clean-up the connectors etc..

@akumpu
Copy link
Author

akumpu commented Dec 11, 2019

Looks nice now.
after using IPA the connection is much more stable now.
But I'll follow it.

@Pogman
Copy link
Collaborator

Pogman commented Dec 11, 2019

Just a thought... maybe get a phone that is known to work well for this and be done with it. I've been running for nearly 4 years with Sony Xperia Z3 Compact going 24/7 and it has a separate charge connector to the usb. Also use a stripped down CNL taped to back of phone and with this low profile it runs very solid for months on end.

CNL-mod-1

@akumpu
Copy link
Author

akumpu commented Dec 12, 2019

Nice idea to strip it down.
Thanks for the tip. Sony sounds quite reliable HW, perhaps I bomb my Huawei and switch to Sony.
It would be nice, if we could collect a list from working HW + SW envs with Medtronic.

@akumpu
Copy link
Author

akumpu commented Dec 12, 2019

This seem to be Huawei specific issue.
I set display to sleep after 30min of inactivity. And it started to work smoothly without any E86 or USB disconnection.
Next I changed display to sleep after 30s of inactivity. And then I got a bunch of errors E86 + USB errors.
So lessons learned: Never buy anything from Huawei :(
Perhaps it is time to switch Huawei to Galaxy J5. But first I have to fix its broken display to able to try it.
Similar kind of fights is ongoing in here:
AltBeacon/android-beacon-library#778

@akumpu
Copy link
Author

akumpu commented Dec 15, 2019

Yesterday I got a new display to J5, and the uploader was on overnight without any issues. So my problem is now solved.
Perhaps you should mentioned somewhere:
"Not recommended for use with vanilla Huawei devices, because of aggressive battery strategy" or similar..

@steve8x8
Copy link

@akumpu first I was wondering why you'd want to soak the stick in India Pale Ale - then became aware of yet another (also alcoholic!) meaning of that "IPA" abbreviation ;) Will try thoroughly cleaning the connector, although after so many reconnects, it should be shiny as hell...

Also I'll check whether I can find any images of the CNL inside (FCC site?) - and possibly how to reversibly disassemble it. The image by @Pogman doesn't show anything connected to the internal antenna socket, does it?

@Pogman
Copy link
Collaborator

Pogman commented Dec 17, 2019

@steve8x8 to open the cnl use a thin edged tool to work the shell open starting at the usb end.

cnl-mod-final-notape
cnl-mod-final-notape-rev
cnl-mod-battery-detail
cnl-mod-otg-heads

@aendes
Copy link

aendes commented Dec 24, 2019

Hello,

Device: Huawei Mate 20 lite
Android: 8.1

from my experience in the last 3 days:

  • used the patch from akumpu on latest Version of the Uploader 0.7.1
  • set Power Saving in Settings to "disabled"
  • set "screen/Display off" to highest value which is not "never" (15 Minutes)
  • first charged CNL to 100%

After three days of usage i had no "E86"- Error.

@blad974
Copy link

blad974 commented Feb 2, 2020

HI Akumpu & aendes,
Am facing the same CNL E86 errors on a Huawei 20 lite.
Newbie question, how do I go about applying said patch to the Uploader?
Thanks all for your great work!

@akumpu
Copy link
Author

akumpu commented Feb 11, 2020

@aendes:
About your comment:"set "screen/Display off" to highest value which is not "never" (15 Minutes)"
Does it leave screen on "forever".. Then this is no option for me, because then I'll lose mobility. I.e the battery will drain quite fast

@aendes
Copy link

aendes commented Feb 12, 2020

@blad974 :
You need to install Android Studio, and download the source, change the file and compile the app. After that you can sideload the app.

@pazaan: Maybe you could release a version with these power settings?

@akumpu: I did not set it to never, my settings now are down to 5 Minutes and i have no issues over days.

With these settings i had no E86- Error since days

@blad974
Copy link

blad974 commented Feb 12, 2020

Thanks ever so much. Shall do and test. Cheers.

@akumpu
Copy link
Author

akumpu commented Feb 14, 2020

FYI. setting doesnt work with Honor7s.

@pazaan
Copy link
Owner

pazaan commented Feb 15, 2020

@pazaan: Maybe you could release a version with these power settings?

@aendes - see #262 (comment).
We're very unlikely to make bespoke builds for vendor customisations to Android.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants