Avainsanana Android

Is there any way to override the flash limitation?

23. elokuuta 2021 klo 21.03
Sijainti: Keskustelupalstat: XDA Forums
Avainsanat: Android, Motorola, reddit

Firstly, a big thank you @MSe1969 for keeping my old Moto G (falcon) secure!

My question is about a specific feature: for some reason, Motorola has apparently disabled charging the device when the camera (flash) LED is on (I’ve found at least one Reddit thread confirming this). Do you happen to know if this is a hardware-level limitation, or if there’s any way to override it in the OS/kernel?

I’ve been testing the phone as a security camera, and while it’s otherwise working, in practical use not having the flash LED means having to have a separate light source, adding its own complications (timers and so on).

Vastaa viestiin sen kontekstissa (XDA Forums)

Android 7.1.2 (LineageOS 14.1) is affected

11. maaliskuuta 2021 klo 18.37
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Android, LineageOS

Android 7.1.2 (LineageOS 14.1) is affected.

Vastaa viestiin sen kontekstissa (Github)

Nextcloud is somehow different from other apps in this regard

6. helmikuuta 2021 klo 13.08
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Android, Nextcloud

Nextcloud is somehow different from other apps in this regard, as no other light (white) apps on the same device have this issue. For instance, here’s Play Store on my affected device (running Android 6.0.1):

Screenshot_20210206-124828

Also, I seem to recall this only having started to affect Nextcloud quite recently, perhaps sometime in the past month or so.

Switching to dark mode is a workaround on my device at least (there the Android buttons are light-on-black). I can also confirm that the issue doesn’t affect my newer devices with newer Android.

Vastaa viestiin sen kontekstissa (Github)

Controls remain on screen after switching to fullscreen before video has loaded

21. marraskuuta 2020 klo 13.23
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Android, NewPipe, Samsung, YouTube

Checklist

  •  I am using the latest version – v0.20.3
  •  I checked, but didn’t find any duplicates (open OR closed) of this issue in the repo.
  •  I have read the contribution guidelines
  •  This issue contains only one bug. I will open one issue for every bug report I want to file.

Steps to reproduce the bug

  1. Have a somewhat slow-to-load video (for whatever reason)
  2. Open the video in Newpipe
  3. Before video details (such as duration) have loaded, tap to switch to fullscreen

Actual behaviour

The playback controls remain on screen while the video plays, I have to tap once more to make them go away.

Expected behavior

The playback controls should disappear like they do when switching to fullscreen after the video details have loaded (and playback has begun).

Screenshots/Screen recordings

Device info

  • Android version/Custom ROM version: Android 10 with OneUI 2.5
  • Device model: Samsung Galaxy Tab S5e

Vastaa viestiin sen kontekstissa (Github)

I went back in time using F-droid’s dev archive

20. marraskuuta 2020 klo 18.18
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Android, F-Droid, Nextcloud

I went back in time using F-droid’s dev archive, testing all the way to around when 3.9.2 was released (2019-12-07), and the issue persisted, so this is indeed some weird interaction with the latest server version(s) and particularly the conflicts detection thereof.

Version 20191206 (2019-12-07) exhibited the issue a bit differently, though probably just due to how handling of conflicts on the client end has changed between then and now: one file that did go through got renamed with ”(1)” added to it, even though there was no previously existing copy on the server. A previous attempt to upload the same file (using another client version) had failed, so that’s one possible explanation for why the server thought that a previous copy did exist.

Another file got seeminly stuck in the (client upload) queue, and watching the server log revealed that it was incrementing the added number continuously, always coming up with the same ”could not be located” exception from Sabre\DAV as above. It had run up to 80 when I cancelled the upload from the client, and would have perhaps run indefinitely if I didn’t.

{"reqId":"SmCGdnw4BzFQ5P25wMGV","level":0,"time":"2020-11-20T17:40:54+02:00","remoteAddr":"REDACTED","user":"testituutti","app":"webdav","method":"HEAD","url":"/varasto/remote.php/webdav/Testidataa/DSC_0003%20(75).JPG","message":{"Exception":"Sabre\\DAV\\Exception\\NotFound","Message":"File with name Testidataa/DSC_0003 (75).JPG could not be located","Code":0,"Trace":[{"file":"REDACTED/www/varasto/3rdparty/sabre/dav/lib/DAV/CorePlugin.php","line":81,"function":"getNodeForPath","class":"OCA\\DAV\\Connector\\Sabre\\ObjectTree","type":"->"},{"file":"REDACTED/www/varasto/3rdparty/sabre/event/lib/WildcardEmitterTrait.php","line":89,"function":"httpGet","class":"Sabre\\DAV\\CorePlugin","type":"->"},{"file":"REDACTED/www/varasto/3rdparty/sabre/dav/lib/DAV/Server.php","line":474,"function":"emit","class":"Sabre\\DAV\\Server","type":"->"},{"file":"REDACTED/www/varasto/3rdparty/sabre/dav/lib/DAV/CorePlugin.php","line":262,"function":"invokeMethod","class":"Sabre\\DAV\\Server","type":"->"},{"file":"REDACTED/www/varasto/3rdparty/sabre/event/lib/WildcardEmitterTrait.php","line":89,"function":"httpHead","class":"Sabre\\DAV\\CorePlugin","type":"->"},{"file":"REDACTED/www/varasto/3rdparty/sabre/dav/lib/DAV/Server.php","line":474,"function":"emit","class":"Sabre\\DAV\\Server","type":"->"},{"file":"REDACTED/www/varasto/3rdparty/sabre/dav/lib/DAV/Server.php","line":251,"function":"invokeMethod","class":"Sabre\\DAV\\Server","type":"->"},{"file":"REDACTED/www/varasto/3rdparty/sabre/dav/lib/DAV/Server.php","line":319,"function":"start","class":"Sabre\\DAV\\Server","type":"->"},{"file":"REDACTED/www/varasto/apps/dav/appinfo/v1/webdav.php","line":84,"function":"exec","class":"Sabre\\DAV\\Server","type":"->"},{"file":"REDACTED/www/varasto/remote.php","line":167,"args":["REDACTED/www/varasto/apps/dav/appinfo/v1/webdav.php"],"function":"require_once"}],"File":"REDACTED/www/varasto/apps/dav/lib/Connector/Sabre/ObjectTree.php","Line":173,"CustomMessage":"--"},"userAgent":"Mozilla/5.0 (Android) Nextcloud-android/20191207","version":"20.0.1.1"}
{"reqId":"M3RTK4KRuOH3N0xGrp2Q","level":0,"time":"2020-11-20T17:41:00+02:00","remoteAddr":"REDACTED","user":"testituutti","app":"webdav","method":"HEAD","url":"/varasto/remote.php/webdav/Testidataa/DSC_0003%20(76).JPG","message":{"Exception":"Sabre\\DAV\\Exception\\NotFound","Message":"File with name Testidataa/DSC_0003 (76).JPG could not be located","Code":0,"Trace":[{"file":"REDACTED/www/varasto/3rdparty/sabre/dav/lib/DAV/CorePlugin.php","line":81,"function":"getNodeForPath","class":"OCA\\DAV\\Connector\\Sabre\\ObjectTree","type":"->"},{"file":"REDACTED/www/varasto/3rdparty/sabre/event/lib/WildcardEmitterTrait.php","line":89,"function":"httpGet","class":"Sabre\\DAV\\CorePlugin","type":"->"},{"file":"REDACTED/www/varasto/3rdparty/sabre/dav/lib/DAV/Server.php","line":474,"function":"emit","class":"Sabre\\DAV\\Server","type":"->"},{"file":"REDACTED/www/varasto/3rdparty/sabre/dav/lib/DAV/CorePlugin.php","line":262,"function":"invokeMethod","class":"Sabre\\DAV\\Server","type":"->"},{"file":"REDACTED/www/varasto/3rdparty/sabre/event/lib/WildcardEmitterTrait.php","line":89,"function":"httpHead","class":"Sabre\\DAV\\CorePlugin","type":"->"},{"file":"REDACTED/www/varasto/3rdparty/sabre/dav/lib/DAV/Server.php","line":474,"function":"emit","class":"Sabre\\DAV\\Server","type":"->"},{"file":"REDACTED/www/varasto/3rdparty/sabre/dav/lib/DAV/Server.php","line":251,"function":"invokeMethod","class":"Sabre\\DAV\\Server","type":"->"},{"file":"REDACTED/www/varasto/3rdparty/sabre/dav/lib/DAV/Server.php","line":319,"function":"start","class":"Sabre\\DAV\\Server","type":"->"},{"file":"REDACTED/www/varasto/apps/dav/appinfo/v1/webdav.php","line":84,"function":"exec","class":"Sabre\\DAV\\Server","type":"->"},{"file":"REDACTED/www/varasto/remote.php","line":167,"args":["REDACTED/www/varasto/apps/dav/appinfo/v1/webdav.php"],"function":"require_once"}],"File":"REDACTED/www/varasto/apps/dav/lib/Connector/Sabre/ObjectTree.php","Line":173,"CustomMessage":"--"},"userAgent":"Mozilla/5.0 (Android) Nextcloud-android/20191207","version":"20.0.1.1"}

Vastaa viestiin sen kontekstissa (Github)

build.sh uses bashisms, but shebangs /bin/sh

14. marraskuuta 2020 klo 14.23
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Android, Bash, Dash, Debian, LXC, Mattermost, Ubuntu

1.37.0 fails to build in my build environment (Ubuntu 18.04 in LXC) with this error:

ubuntu@mattermost-mobile:~/mattermost-mobile$ npm run build:android

> mattermost-mobile@1.37.0 build:android /home/ubuntu/mattermost-mobile
> ./scripts/build.sh apk

./scripts/build.sh: 3: ./scripts/build.sh: Syntax error: "(" unexpected
npm ERR! code ELIFECYCLE
npm ERR! errno 2
npm ERR! mattermost-mobile@1.37.0 build:android: `./scripts/build.sh apk`
npm ERR! Exit status 2
npm ERR! 
npm ERR! Failed at the mattermost-mobile@1.37.0 build:android script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/ubuntu/.npm/_logs/2020-11-14T11_47_00_288Z-debug.log

The top of that file, build.sh, refers to /bin/sh, but on Ubuntu and Debian, /bin/sh has been Dash for quite a while, whereas build.sh seems to written for Bash (where function is a valid keyword):

ubuntu@mattermost-mobile:~/mattermost-mobile$ head scripts/build.sh 
#!/bin/sh

function execute() {
    cd fastlane && NODE_ENV=production bundle exec fastlane $1 $2
}

I suggest switching the shebang to #/bin/bash, or better yet, #!/usr/bin/env bash (for path-agnosticity). In my environment, using either one fixes the build.

Vastaa viestiin sen kontekstissa (Github)

Yup, tried it and the issue remains

11. marraskuuta 2020 klo 18.19
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Android, Nextcloud

@tobiasKaminsky Yup, tried it and the issue remains. Also found a device with 3.13.1, and it too is affected now, so this now seems more server-related, though it is weird that the desktop client hasn’t been affected at any point. I would have assumed both clients employ the same webdav commands (and thus fail or succeed just the same).

Syncing a folder in Android app’s ”all files” view also still works (i.e. downloading changes causes no issues).

I have another server instance on another host, and there uploading from Android still works. This (working) instance is unencrypted, while the non-working instance has server-side encryption enabled.

Vastaa viestiin sen kontekstissa (Github)

There’s a ”Deprecated event type” followed by ”Exception”:”Sabre\\DAV\\Exception\\NotFound”

5. marraskuuta 2020 klo 20.50
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Android, Nextcloud

With more verbose logging server-side, there’s a ”Deprecated event type” followed by "Exception":"Sabre\\DAV\\Exception\\NotFound" for the file being uploaded. So it’s perhaps correctly reporting that the file (about to be uploaded) does not exist (yet), but for some reason the app receiving this message flips it around, thinking the file does exist, and thus reports a conflict.

Vastaa viestiin sen kontekstissa (Github)

The result of ”Existence check” comes back as ”Name collision”

5. marraskuuta 2020 klo 20.39
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Android, Nextcloud

Here’s a logcat snippet from another device. The result of ”Existence check” comes back as ”Name collision”, for any and all files.

Vastaa viestiin sen kontekstissa (Github)

3.14.0 RC1 can not upload anything (and is generally just broken)

1. marraskuuta 2020 klo 16.20
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Android, Nextcloud

In short

Since updating the Android app to 3.14.0 RC1 (and server to 20.0.1 earlier), I can not upload anything with the app. Desktop client still syncs just fine.

Steps to reproduce

Try to upload a file (either manually or by taking a photo for auto-upload)

Expected behaviour

File should get uploaded

Actual behaviour

There’s a notification about ”File upload conflict”. Selecting the notification results in ”Error creating conflict dialog”. Going to uploads view and selecting ”Resolve conflict” for a file just results in ”Sync conflict, please resolve manually”.

Can you reproduce this problem on https://try.nextcloud.com?

Trying to add an account in the app causes the app to crash.

Environment data

Android version: 10
Device model: Samsung Galaxy A9 (2018)
Stock or customized system: stock
Nextcloud app version: 3.14.0 RC1 (from Beta channel)
Nextcloud server version: 20.0.1
Reverse proxy: no

Logs

Web server error log

Nothing NC-related

Nextcloud log (data/nextcloud.log)

Nothing related to the uploads, just

Vastaa viestiin sen kontekstissa (Github)

Vanhempia »