Syncthing-android: "Syncthing is disabled" even though it should be running

[axet]

Time-to-time syncthing shows disabled screen when I open app. Seems like it can't proper detect my Wifi connection. It been happening for a while (since beginning... a few months...)

App Version: 0.8.3

http://pastebin.com/n7C80d28

[Nutomic]

Seems to be a duplicate of #634. Ping @capi.

[capi]

I noticed it as well on my device recently. WiFi was detected properly according to adb log but subprocess was not started. I have not yet been able to reproduce it and track it down. I'm on it. Unfortunately I'm quite busy at the moment and I have little time to do development, sorry. I think, a sensible approach is to tackle #729 first, so that we get better information why Syncthing is stopped.

[capi]

@Nutomic we might have been looking at this too narrowly with WiFi. I had the issue yesterday twice when _unplugging the device from A/C_. The notification stayed active, clicking on it launched Syncthing in the above state. Only way to get it working again, was to re-plugin to power (then it really started) and then unplugging (and stopping in my case) worked as expected.

Unfortunately the logcat application doesn't work on my phone and until I reached a PC with adb, the log was long gone. But it's interesting to see this behaviour not only related to WiFi but also to A/C-only.

[licaon-kter]

Unfortunately the logcat application doesn't work on my phone a

umm, Termux, su, logcat -v threadtime > /sdcard/log1.txt wait a bit and ^C (VOLUME UP+C) ;)

[capi]

@licaon-kter that would require a rooted phone :)

[achilleas-k]

Might I suggest changing the issue subject to something more specific? I came here for this exact problem, this issue was the most recent, and it was exactly what I was looking for, but I would have never guessed it from the title.

[Ferroin]

I don't know if this helps, but I've noticed on my phone (Nexus 6P running stock Android 7.0) that this happens whenever I leave range of a wireless network then come back into range without connecting to any other network (For example, if I go far enough down the street from my house that I am no longer connected to my home WiFi network, then go back, all without connecting to any other WiFi network).

I can usually get things working again by toggling WiFi on and off again, which is tedious, but works a s a short term workaround.

I've never seen the issue when disconnecting from a charger though.

[capi]

@Ferroin Thanks, its something to investigate towards. Once we have some reproducibility, I'm quite sure it can be solved.

[Ferroin]

Well, for what it's worth, I see this at least once a day on work-days when I take a walk around the block at lunch. While I obviously can't help with the charging related aspect, I'll be happy to help with testing fixes for the WiFi side of things (including side-loading development builds if needed).

[nigelinux]

For what it's worth, I encountered this problem even if my Wifi stayed on. I just find that the problem exist if I turn on built-in battery saver mode on my HTC E8 (I always turn it on for lower screen brightness and CPU usage). Is there any option to turn off this function (i.e. stop Syncthing from running when in battery saver mode)?

And I actually didn't think the battery saver mode is the cause of problem, until a read the release note in Github with this line: "respect battery saving mode and global sync setting". I hope there is clearer instruction when implementation such new functions.

I'm not sure if it is the right place or should it open it as a separate issue. Please advise.

[capi]

@nigelinux Please open a separate issue for the "battery saver mode" change so that we don't mix the discussions.

[Ferroin]

OK, now that I'm actively paying attention, I'm noticing that while leaving WiFi reliably triggers it for me, it also happens pseudo-randomly. Just over the weekend, I've been trying to watch it whenever I can,. I've never seen when it actually happens, but it appears that the phone has to sleep, and Syncthing has to be idle (everything in sync, nothing being transferred.

On a hunch, I tried disabling Battery Optimization for Syncthing from the system settings (in stock Android 7.0, go to the Battery section of settings, hit the 3 dots in the top right and select battery optimization, then find Syncthing in the list and turn off Battery Optimization for it, note that this is not the same as Battery Saver mode), and that seems to help a bit, but not completely fix this.

[capi]

@Ferroin Have you tried enabling "Run service with foreground priority" from the "Experimental" section?

[Ferroin]

@capi I'm not certain I've seen that anywhere in the settings, I'll double check and see if I can find it, and if so, I'll try that too.

[licaon-kter]

Do check out: battery optimisation turns off global Synchronization when activated?

[Ferroin]

@licaon-kter Battery Saver mode does turn off global sync when enabled, but Battery Optimization is different from that, and shouldn't directly affect that.

Battery Optimization does a bunch of things on a per-app basis based on usage and other factors to try and reduce the application's battery usage without impacting it's usability. It does things like suspending apps which aren't in the foreground when the foreground component hasn't been used in a while, which is what I think is part of what is happening here.

@capi I haven't been able to find any option with a name like that anywhere in any of the settings on my phone (including in the Developer options and the System UI Tuner).

[licaon-kter]

Umm, Syncthing respects global sync state, hence... battery optimisations stops sync which in turn stops Syncthing.

[Ferroin]

@licaon-kter Like I said, Battery Saver Mode is _NOT_ the same as Battery Optimization, the two are two different things operating in different ways at different levels doing different things. Battery optimization is a normal runtime mechanism that does regular things that don't break any guarantees provided by the Android API. Battery Saver Mode (at least on stock Android) is intended to be a last ditch effort to keep the device operation at a minimal level when the battery is low (the default in 7.0 is to turn it on at 5% remaining charge). Syncthing should be essentially non-functional when Battery Saver Mode is on, but Battery optimization should not impact it to this degree. Given what Battery Optimization does, the only impact should be that it takes longer for Syncthing to see changes (either local or remote) when it's enabled.

[capi]

@Ferroin It's a setting in Syncthing's "Experimental" section.

[Ferroin]

Ah, that would explain why I couldn't find it in the system settings...

FWIW, since turning off Battery Optimization for Syncthing, I've only seen this issue under the conditions I outlined above with leaving and reentering a WiFi network. Given that, I'll try with the foreground priority option on and Battery optimization enabled and see if that gets similar results. Based on what I know about Battery Optimization, I think that should have the net result of making it think the app is constantly in use.

[Ferroin]

OK, just preliminary results, but it looks like setting Syncthing to run the service with foreground priority is helping to the same degree as disabling Battery Optimization for Syncthing. It appears to at least reduce the random issue, but not the issue I see when leaving range of a WiFi network then reentering range. Of course, this is just on my system, so it would be great if someone else could check as well.

[Ferroin]

OK, further update, running the service with foreground priority doesn't seem to help much by itself, as it had no noticeable impact. So far based on what I've tried, disabling Battery Optimization for Syncthing seems to be the most reliable fix for me, but I still have the issues with it getting into a disabled state when I leave range of WiFi. If anyone else has any further suggestions, I'll be happy to help test them.

[jebeld17]

I've had the same problem.
The issue seems to be that it will give this error message correctly the first time due to a trigger (such as WiFi being off, etc.), but the user needs to soft-close the app (swiping away the task in the Recent Tasks view) and re-open once the app is connected to WiFi, etc.
Basically, the "warning" message the app gives the user doesn't clear until the user clears it his or herself, either by soft-closing the app or clicking "change settings" (albeit may not even be changing settings).

[Ferroin]

OK, this is odd, I haven't seen this issue any more since I reset my phone to enable file-level encryption right around the same time that I got the update to 0.8.4 for syncthing-android. I've still got things set so battery-optimization is disabled for Syncthing, and it's not running the service in the foreground.

[Ferroin]

I've now only seen this once since I last posted about it, and I was able to trace that one time to being on a WiFi network that didn't actually have an internet connection then switching to one that did. I'm not sure if this is fixed for anyone else, but it seems to be working correctly for me now.

[capi]

Hmm, at the moment we are listening for CONNECTIVITY_ACTION. According to http://stackoverflow.com/a/5890104, it could also be required to listen for android.net.wifi.STATE_CHANGE.

[Ferroin]

OK, more data. If I connect my phone to a network through a USB Ethernet adapter, and then disconnect from that network, Syncthing will afterwards constantly claim to be disabled regardless of the state of WiFi, and toggling WiFi or the 'Only Sync on WiFi' setting don't help (I'm checking now if a full reboot of the phone fixes things).

[axet]

I'm using this tricks in my app (Wifi only option)

https://github.com/axet/android-torrent-client/blob/master/app/src/main/java/com/github/axet/torrentclient/app/Storage.java#L364-L452

[acolomb]

Considering the aspect of WiFi networks without an internet connection, could you please check if the app can be notified also when reaching that connection state?

I have a laptop connected to a WiFi router with no internet uplink. When I take my phone there, it would be nice if syncthing was activated and synced with the laptop. The mesh network nature of syncthing is ideal for this kind of direct client connection without access to any central server.

But currently the app stays disabled because Android regards the WiFi as "broken".

[Nutomic]

@acolomb https://github.com/syncthing/syncthing-android/issues/540#issuecomment-221529625

[acolomb]

Thanks for the hint, had not seen that issue. I thought maybe since the changes on Android 7 require a code change anyway, this could have changed in the meantime.

Hmm, at the moment we are listening for CONNECTIVITY_ACTION. According to http://stackoverflow.com/a/5890104, it could also be required to listen for android.net.wifi.STATE_CHANGE.

No clue about Android APIs, but that sounds like it might give more detailed information about the WiFi state?

[wweich]

AFAIK, if the WIfi has no internet and you have a working cell data connection, you cannot ever connect to devices on the Wifi.
I tried to access the admin interface of the router to activate internet by using the internal ip, but every browser on Android told me, that it couldn't connect.

So even if Syncthing was running, all traffic would still go through cell data.

To connect to a Wifi without internet, you have to disable cell data in the Android settings. Then Android will tell Syncthing that it has a Wifi connection.

[Ferroin]

AFAIUI based on what I've seen from other apps, it's if you can't get an IP that you can't talk on WiFi. I do know it behaves differently with a captive portal versus not being able to determine an upstream router though, so that may have something to do with it.

[stuarta0]

FWIW I've been getting this behaviour for a couple of months now. Nexus4 CM13 (Android 6.0.1), ST-Android 0.8.8, ST 0.14.9.

Never turn WiFi off, use case is leaving home WiFi, connecting to work WiFi, then back to home at the end of the day. Only plugged in overnight for charging. Options are to run in background, sync on wifi and use advanced folder picker. No WiFi network restrictions, no metering on WiFi (but metered OTA). Only by disabling sync on wifi does it start working.

[gerroon]

I still get this with 0.9.0 on Lolipop. The wifi is on and when I enable only sync on wifi, it wants me to change the settings refuses to run properly. Nagging me about syncthing being disabled with a pop up.

Not only that but disabling the wifi only is not enough, it stills nags about it. I have to disable the sync only when charging option to get it running.

This apps get weirder and weirder by day, sorry to say this.

I just wished that the run in background is not ttied to the wifi and the charging options. They should be separate things.I want to run syncthing only when charging but I do not want to run it in the bg at all times at all.

[gerroon]

I still have this issue with 0.9.2

thanks

[jebeld17]

It's being caused by the Doze feature built into Android, which will only get worse in Nougat for the common user that may not know why these problems are being triggered.
Luckily I've noticed in the past weeks that ST has added a warning screen mentioning the user to remove Syncthing from the list of optimized apps with simple and quick instructions to go along.

[jebeld17]

@Axet, what type of device are you running this on? Samsung? HTC? Sony?
I haven't had time to go through the details

[axet]

@jebeld17 lg nexus 5

[Ferroin]

FWIW, disabling Battery Optimization (the official name for the Doze feature as connected to apps) makes it work about 99% of the time for me on Android 7.0+ (I've tested every version from 7.0 to 7.1.1) on my Nexus 6P. There are still a few corner cases where Syncthing gets confused:

1. Hooking up a USB Ethernet adapter (which I do sometimes at work to quickly check network connections) will reliably confuse Syncthing until you restart the phone.
2. Hooking up to a Bluetooth PAN connection (using another phone to get a network connection over Bluetooth) seems to mostly reliably confuse Syncthing, but toggling Wi-Fi after disconnecting from the Bluetooth PAN will get Syncthing working again.
3. I still on rare occasion (about once every 2 weeks or so out of about a dozen or so times a week it could happen) see this issue when leaving the range of a Wi-Fi network for more than a couple of minutes then re-enter range it without connecting to different Wi-Fi network.

[achilleas-k]

I've been using the app with the experimental Foreground Priority for about a week and I think it solved it for me.

[Ferroin]

I've seen pretty much the same results doing that, but using Foreground Priority instead of disabling Battery Optimization actually drains my battery faster, hence my preference to disable Battery Optimization for Syncthing.

[jebeld17]

Every device is different and every manufacturer applies their own rules, etc. on top of what Google already has, so my issue I had was caused by HTC's Boost+ app built into the Android with Sense OS itself for HTC devices.
Just removing Syncthing from the Doze feature doesn't cut it for me because there is an entirely different app doing what Android is already doing on it's own terms running simultaneously.

[jebeld17]

I assume you do not have any "app-killing" apps running in the background constantly, correct?

[Ferroin]

No, the only things I have running in the background beyond the stock Android stuff (Google Play Services, Now Launcher, etc) are Syncthing and BOINC (which only actually does anything when the phone is on a charger and at 90%+ charge). The Nexus 6P is also true stock Android (with a small amount of work, it's actually possible to run AOSP on it), so I'm lucky enough not to have to deal with vendor bloatware getting in the way.

TBH, there's not really much that Syncthing can do regarding crap like Boost+ other than telling people it is known to cause issues (and may be causing issues with other stuff they have on their phone too).

[jebeld17]

BOINC could be causing the Syncthing process to end abruptly.
Reason why is because BOINC is very heavy on system resources (given the right conditions), and if you do not have many files and computing power Syncthing needs to access from Android, Android could be killing the Syncthing process anyways in order to give more room and processing power to BOINC that is in the highest demand.

I would recommend bringing your processing requirements for BOINC down by half and seeing how Syncthing responds to that.

[gerroon]

I already disabled the battery optimization and I still got the problem.

[jebeld17]

@gerroon @Ferroin that doesn't necessarily mean Syncthing will stay active. The nature of the OS is to kill off the less needed background tasks to make room for more energy consuming tasks, such as BOINC. If your phone begins to run out of resources, Android will always begin to do this just by nature of design.

[Ferroin]

I never have this issue when at home with the phone on a charger, which is the only time BOINC is actually doing anything other than sitting there in memory waiting for a notification that the phone got connected to a charger, so I'm pretty certain it's not BOINC. Also, given standard operation design of Android combined with how BOINC tags itself, BOINC will get killed first (I've actually tested this before) because it uses more memory than anything else on the phone and identifies as a low-priority task.

Like I said earlier though, the only cases I actually see issues now that Battery Optimization is off for Syncthing and I'm using Android 7.0+ are when doing odd networking things (USB Ethernet or acting as a Bluetooth NAP/DUN client), or on rare occasion under the conditions I used to see it (leave range of a Wi-Fi network, then re-enter range after more than about 5 minutes without connecting to another Wi-Fi network). In all cases, it's infrequent enough that it's just an annoyance, not something that makes Syncthing unusable. In the odd networking use cases, I've seen other apps which try to only run when a Wi-Fi connection is active freak-out and stop working as well, so I'm inclined to believe that it's just not an easy problem to solve.

[jebeld17]

@Ferroin
Is there anything running - in the foreground or background - that may be eating up resources? This is disregarding Syncthing.

PS: Although BOINC may not be actually computing at the time when your phone is unplugged, BOINC is still allowed to hold processes in the RAM and cache. If BOINC has a higher priority in any way, shape, or form in Android over ST, Android will still kill off ST first if other apps begin to use up the remaining x% of RAM (and cache in some cases).

PS PS: I read your previous message over again, I now see that you have already tested how BOINC behaves with Android's built-in task killing ways while unplugged - But regardless, maybe BOINC is still being seen as a higher priority task over Syncthing?

[jebeld17]

@Ferroin @gerroon @axet
Can you grab Android debugging logs using the built-in Android Debugger in the Developer Options < Bug Report Shortcut?
This will give everyone even more insight into what is actually going on with the phone in it's entirety, not just one app.

[gerroon]

I just upgraded another of my device (Kitkat) to 0.9.2 now it keeps nagging me to change settings, pretty much I have to disable all the run conditions to get this running. This was perfectly working with 0.8.8, another sad day for me because of Syncthing App.

I have to disable when on wireless and when charging conditions. So this is nt just about recognizing the wifi stuff. Somewhere in the logic of this application something is just plain wrong I presume.

[gerroon]

@jebeld17

I was talking about "change settings" mess up not killing bg processes. On the other hand I do not any kind of background optimization etc type apps running on any of my devices,

[Ferroin]

The largest offender right now for memory usage (out of the 3GB that the system has) that isn't part of Android itself on my phone is VLC, at 117MB (but I've been playing music most of the morning). Excluding that (since it's not always running), the next biggest is GMail at 34 MB. The average usage is about 2GB (even when BOINC is running), so I doubt that memory is the issue.

As for processor utilization, it rarely goes above 25% when BOINC isn't actively processing work (which is most of the time).

I assume you'd like the debug log to be from when things aren't working? If so, it may be a while, if you just want a generic one for Syncthing, I can have that posted somewhere on-line in a about an hour.

PS: I assume you want an interactive report for Syncthing, not a full report?

[Ferroin]

Slightly more info, it looks like the USB Ethernet case confuses both BOINC and Android's built-in download manager as well, so i don't think that's actually an issue with Syncthing, just a problem with Android itself.

[jebeld17]

I was mainly recommending a debug log. I'm not a dev, but an Android debugging log will certainly help the devs out.

[jebeld17]

As far as the USB Ethernet part, I would and could only assume that the Android OS is putting itself into a lower power mode thinking the USB device it is attached to is stealing power from your phone.
That said, it's only an assumption.
Have you tried reporting the issue on Google's official bug tracking system for Android software issues?
https://code.google.com/p/android/issues/entry?template=Developer%20bug%20report

[jebeld17]

Actually, duh I don't know why I didn't think of this earlier:
Does your phone let you still be connected to Wifi and also tether via USB? Mine doesn't and I am running the same version of Android.
Maybe I'd need to read upwards more in the thread a bit 😊

[Ferroin]

In this case, it's not tethering in any traditional sense, I'm literally hooking a USB GbE adapter up to my phone. I've not tried sharing a connection from another device to my phone over USB, and I don't have the hardware to be able to test such a setup, although I doubt that would be much different (RNDIS versus CDC Ethernet endpoints, but that shouldn't have any impact because it is (or at least, it should be) below the level at which Android's connection management runs).

Now, as far as the USB GbE adapter, I think I know why it causes issues with Android's download manager, and there's nothing that could be done about that without using mobile IPv6 (routing table update, the ethernet link becomes the default route, the connection over Wi-Fi gets confused and breaks). The Wi-Fi does stay active (I've watched with Wireshark and still see frames from the phone's wireless adapter), but that got me thinking, what if Android is sending a notification that the Wi-Fi connection has been lost (even though it hasn't) when the Ethernet link comes up, and then never sends the event that Wi-Fi is working again when the Ethernet link is removed? I would assume internally that the checks are a state-machine, and it could just be getting into an undefined state as a result of the change in connection.

I'll get a debug log posted for the USB Ethernet case since I can reliably get that to happen.

[Ferroin]

Ok, this is odd, the USB Ethernet case seems to be working fine now. The only difference since I last tested it is that I was running Android 7.1.0, and I'm now running 7.1.1.

[jebeld17]

Definitely share the debug logs, especially with Google at the link I gave above :)
Who knows, maybe they didn't patch the issue but it just isn't happening on your build?

[rebroad]

this is also a problem on android 6.0

[licaon-kter]

Do detail your settings.

[yhaenggi]

Can we have a revert of the power saving "feature" or an option to disable said "feature"? This kinda annoying. Having Power Saving on all the time is a perfect valid use-case.

[Nutomic]

@K1773R That seems to be a seperate issue. Would you mind opening a new issue for that?

[Ferroin]

I've had a couple of rounds of monthly Android updates since I last posted, and as long as I keep Battery Optimization off for Syncthing, I can't get this to reproduce on my phone at all now, regardless of what I do. I'm starting to think the cases I was still seeing even with Battery Optimization off were corner cases in Android itself, not Syncthing, and that they've finally gotten fixed.

To recap slightly, I had been seeing this on Android 5 and Android 6, but do not see it any more on an up-to-date version of stock Android 7.1.1 with Battery Optimization turned off for Syncthing. While other people are obviously still having issues, it seems to be resolved for me.

[jebeld17]

I have an update on my end:

I still receive the "Syncthing is Disabled" message on my devices, though the message now doesn't disappear until I hard-close or force-quit the app through my System Settings and restart the app.

ST Info:
Android Version: 0.14.24
ST Version: 0.9.7

Castro Information Report

Report generated: 25 March 2017 13:44:22

System
OS
Version: Nougat 7.0
Security patch: 01 January 2017
Build number: NRD90M
Tags: release-keys
Bootloader: 1.0.0.0000
SDK: 24
Font scale: Normal
Time zone: Eastern Standard Time
Uptime: 04:42:40
Uptime (w/o Deep Sleep): 11:49:06
Radio: 1.0.U010241a@61107_76.02_F

Miscellaneous
Disk encryption: Decrypted
Virtual machine: ART 2.1.0
Heap size: 512 MB
SELinux: Enforcing
Root: Unavailable
BusyBox: Unavailable
Version ICU: 8.0
Library ICU: 56.1
ICU CLDR: 28.0
Version ZLib: null
Version OpenSSL: BoringSSL
Kernel: 3.18.31-perf-gc6d4936 and@AABM) ) #1 SMP PREEMPT Mon Jan 16 17:55:10 CST 2017
Fingerprint: htc/pmewl_00617/htc_pmewl:7.0/NRD90M/857212.3:user/release-keys

Device
Model: HTC 10
Codename: htc_pmewl
Manufacturer: HTC
Fingerprint scanner: Present

Display
Resolution: 2560 x 1440 pixels
Frame rate: 60 Hz
Density: 640 dpi
Format: xxxhdpi

Identifiers
HIDDEN FROM FILE

Processor

CPU
Model: Error
Name: AArch64 Processor rev 2 (aarch64)
Architecture: Error (0x211)
DSP: Error
Process: Error
Cores: 4
Supported ABI: armeabi
Governor: interactive
Frequency range: 307 MHz - 1593 MHz
Usage: 83 %

Power saving
Multicore saving: Disabled

Technologies
NEON: Not supported
SWP: Not supported
Thumb: Not supported

GPU
Name: Error
Frequency: Error
Minimal frequency: Error
Maximal frequency: Error
Governor: Error
Open GL: OpenGl ES 3.2

Battery
Capacity: 3000 mAh
USB Fast charging: Not supported

Memory
RAM Total: 3766 MB
Internal memory Total: 23.91 GB
SWAP memory Total: 2047 MB
SWAP memory Cached: 11 MB
Buffer memory Total: 24 MB
External memory Total: 59.60 GB

Cellular
Phone
Operator: AT&T
Operator code: 310410
Standard: GSM
Country code: us
Voice mail: Supported
World phone: Yes

Network
Type: 4G
Status: Disconnected
Roaming: Disconnected
ICC card: Present
Local (IPv4): 192.168.86.131
Local (IPv6): HIDDEN FROM APP
Current TCP: cubic
Available TCP: cubic reno

Wi-Fi
Properties
Name: "Google OnHub"
Hidden SSID: Disabled
Frequency: 2437 MHz
Speed: 26 Mbps
BSSID: HIDDEN FROM APP
Signal: -74 dBm
Local IP: 192.168.86.131
5GHz band: Supported

DHCP
DNS 1: 192.168.86.1
DNS 2: 0.0.0.0
Gateway: 192.168.86.1
Lease time: 24 hours
Subnet mask: 0.0.0.0
Server IP: 192.168.86.1

Back camera
Resolution: 12.0 MP (4000x3000)
JPEG quality: 90 %
Thumbnail size: 320x240
Thumbnail quality: 90 %
Focal: 4.58 mm
Auto exposure: Unlocked
Auto white balance: Unlocked
Vertical angle: 53.8285 %
Horizontal angle: 10
Horizontal angle: 10
Video stabilization: Error
Flash: Available
Zoom: Available

Color effect
Current: Not selected
Supported: Not selected, Monochrome, Negative, Solarize, Sepia, Posterize, Whiteboard, Blackboard, Aqua

Focus mode
Current: Automatic
Supported: Infinity, Automatic, Close-up, Continuous video, Continuous picture

Scene mode
Current: Automatic
Supported: Automatic, Landscape, Snow, Beach, Sunset, Night, Portrait, Sport, Steady photo, Candlelight, Fireworks, Party, Night portrait, Theatre, Action

Antibanding mode
Current: Automatic
Supported: Disabled, 60 Hz, 50 Hz, Automatic

Front camera
Resolution: 5.0 MP (2592x1944)
JPEG quality: 90 %
Thumbnail size: 320x240
Thumbnail quality: 90 %
Focal: 2.35 mm
Auto exposure: Unlocked
Auto white balance: Unlocked
Vertical angle: 57.9945 %
Horizontal angle: 10
Horizontal angle: 10
Video stabilization: Error
Flash: Unavailable
Zoom: Available

Color effect
Current: Not selected
Supported: Not selected, Monochrome, Negative, Solarize, Sepia, Posterize, Whiteboard, Blackboard, Aqua

Focus mode
Current: Automatic
Supported: Infinity, Automatic, Close-up, Continuous video, Continuous picture

Scene mode
Current: Automatic
Supported: Automatic, Landscape, Snow, Beach, Sunset, Night, Portrait, Sport, Steady photo, Candlelight, Fireworks, Party, Night portrait, Theatre, Action

Antibanding mode
Current: Automatic
Supported: Disabled, 60 Hz, 50 Hz, Automatic

[Nutomic]

This should be fixed in 0.10.0. If you still have this problem, please open a new issue with logs.