[HN Gopher] Syncthing Android App Discontinued
___________________________________________________________________
Syncthing Android App Discontinued
Author : opengears
Score : 311 points
Date : 2024-10-20 14:51 UTC (8 hours ago)
(HTM) web link (forum.syncthing.net)
(TXT) w3m dump (forum.syncthing.net)
| jsiepkes wrote:
| There is an Android Syncthing fork [1] which is active and 1.3K
| stars (for whatever that's worth).
|
| [1] https://github.com/Catfriend1/syncthing-android
| felurx wrote:
| I've been using that one for a long time now. I recall that
| when I got started with Syncthing (some months to a year or two
| ago?), it seemed to have been the folk wisdom to use Syncthing-
| Fork, but I don't recall what the reason was.
| FierySpectre wrote:
| For me, I'm pretty sure it had something to do with better
| and more granular run conditions on folders.
| krick wrote:
| Weirdly enough, I cannot find either on Play right now..even
| though I have it (the original, I believe) installed through
| Play.
| jasonvorhe wrote:
| > Head to the "releases" section or F-Droid for builds.
|
| It's in the description on GitHub. Get F-Droid.
| ajb wrote:
| Good to know, although the Readme says:
|
| "Planning to close my Google Play Developer Account. Please say
| hi if you are interested in obtaining the latest gplay release
| files from me to help in publishing this app."
| Macha wrote:
| It's on f-droid rather than google play.
|
| I think for the people interested in using Syncthing rather
| than Dropbox or Google's syncing option, that's not _that_
| much of a problem.
| stavros wrote:
| It's going to be much less of a problem for everyone, with
| these draconian Play policies, as I imagine more and more
| people will be installing F-droid.
| oakpond wrote:
| Seems to work. Exported the config of the other one and
| imported it in this one. Seems all the settings are there. Sync
| seems to work too. Kudos to the devs.
| SeriousM wrote:
| Yep, that's what I use. Very happy with it for years!
| sabbaticaldev wrote:
| Google is in self-destruct model
| krick wrote:
| It is self-destruct only if you have competition. They don't,
| so it's just destruct.
| hparadiz wrote:
| This is one of the few reasons I was still on Android over
| iOS. If Android becomes just as bad as iOS why would I keep
| putting up with Android?
|
| It's exhausting dealing with operating systems that treat you
| like a child. If that's the choice I may as well not even
| have a "smart" phone. There's nothing smart about it anymore.
| It's become a toy with a camera.
| jasonjayr wrote:
| From the (current) final comment at
| https://github.com/syncthing/syncthing-android/issues/2064
|
| > Nothing came of the discussions with google. Demands by Google
| for changes to get the permission granted were vague, which makes
| it both arduous to figure out how to address them and very
| unclear if whatever I do will actually lead to success. Then more
| unrelated work to stay on play came up (dev. verification, target
| API level), which among other influences finally made me realize
| I don't have the motivation or time anymore to play this game.
| izacus wrote:
| I don't think Google was ever buy a "I don't want to use file
| APIs because writing the code would be hard." excuse for a
| security issue. I don't know what kind of exact "discussions"
| were possible here for "give me access to all user data, photos
| and everything because I don't think I want to use SAF APIs".
| It's like that dude in your company that will have a meltdown
| in PRs over his better way instead of fixing the comments and
| having code submitted.
|
| Apple won't let you write into random directories past their
| APIs either, just because it would be too hard to use
| ObjC/Swift.
| homebrewer wrote:
| Put a lot of scary warnings around it then. It's for the user
| to decide if they want to take the risk or not. Google took
| something that solved real problems better than any
| alternative could, did so for many years, and destroyed it
| for no real reason other than to further tighten control they
| have of the supposedly "open" platform.
| izacus wrote:
| They did, the upstading app developers like this one just
| forced people to give them full access to all data in the
| app (or the app wouldn't run) and ended up not implementing
| scoped storage - something HNers outright demanded several
| times and exposed as a good upside of iOS.
|
| So stick had to come out. The full filesystem access is now
| reserved for apps that manage full filesystem (e.g. file
| explorers) and that's it. Scoped storage APIs were
| introduced in 2013, 11 years ago and Play started enforcing
| them in 2020, so the experiment with scary warnings was
| running for 7 years and developers refused to give up on
| that sweet full private file access.
|
| Granted, SAF is quite a shitty API.
| monocasa wrote:
| I mean, syncthing is exactly the kind of app I would
| expect to have full filesystem access.
| growse wrote:
| Why? I want it to have access to the folders I want it to
| sync, not _everything on my device_.
|
| Seems like a perfect fit for SAF.
| lukeschlather wrote:
| In a perfect world, what Syncthing does would be handled
| at the OS level and all OSes would seamlessly
| interoperate. In the real world the OS vendors are
| hostile to interoperability so the only way to get that
| is with a third-party tool that has OS-level access.
| izacus wrote:
| There are Android APIs to let syncthing integrate as
| cloud provider itself and the author didn't use those
| either.
| evilduck wrote:
| In reality, Syncthing is also pretty good at destroying
| battery life unless you go above and beyond to configure
| it in a way that then hampers Syncthing's ability to
| provide seamless file continuity between devices. I know
| that there will be disagreement here, but in my own
| opinion OS vendors are correct in being hostile to these
| apps under current circumstances. They could provide
| better ways to have third parties implement it and
| provide cross platform support for their platform
| solutions, but I've had Syncthing be the #1 cause of
| battery life drain on multiple devices and platforms
| before and it's honestly just not worth fighting with it.
| To get it under control relegates it to being not much
| better than rsync.
| Zak wrote:
| I think it's important to draw a distinction between OS
| providers and app store providers here. The fact that
| they're the same entity in most cases is or should be
| largely irrelevant.
|
| OS vendors shouldn't make it impossible to create apps
| that have unlimited access to the filesystem or that suck
| battery in the background. There are reasons users might
| want to run apps that do either or both - a file indexer,
| for example. All the OS should do is ask the user if the
| app has permission to do those things.
|
| An app store provider on the other hand might reasonably
| have many criteria for inclusion, such as F-Droid only
| allowing FOSS. This only becomes problematic when the app
| store in question is effectively a monopoly.
| sdoering wrote:
| No. Not in my world. Because I actually want to be able
| to backup my phone - not only demarcated parts of it.
|
| I want to be able to get all data from my phone -
| regardless of what it is and what app put it there.
|
| If I decide to only sync specific folders. So be it. But
| I want to be able to sync "/"
| pmontra wrote:
| I want it to be able to browse to another app's private
| folder to sync the data of that app to my computer. If
| browsing to there it's not the job of syncthing then I
| need a file manager with those permissions.
| andrepd wrote:
| For 3 years now I can't open my Downloads or Pictures
| folder without root, because their _shitty_ API is
| unbelievely bad that it would take around 30 minutes to
| open a folder with that many files.
| out_of_protocol wrote:
| > Seems like a perfect fit for SAF.
|
| Except SAF is slow as hell, working on multiple files
| means separate calls for every little thing like file
| size via java API. Means everything going to be VERY slow
| and drain battery a lot. I've seen test from 2019 where
| directory listing operation is 25-50 times slower in SAF
|
| https://issuetracker.google.com/issues/130261278
| smashed wrote:
| It's _my_ phone. It 's _my_ data. It 's _my_ choice to
| install the app. It 's _my_ choice to grant the
| permissions to all files. Because guess what, I 'm using
| the app to sync all my files.
|
| I really can't agree with Google in this particular case.
| izacus wrote:
| And yet you'll blame Android when some app steals a lot
| of data just like it always happens on this site.
| swatcoder wrote:
| Have you considered that it's a plural "you" that you're
| choosing to pit yourself against, with different people
| each weighing different complaints?
|
| Almost by definition, the people who argue strongly for
| free use of their hardware and software are almost never
| the same people who argue strongly for safety and
| security restrictions. You seem to be frustrated by a
| contradiction or inconsistency that doesn't exist.
|
| It's true that Google can't win the hearts of both sides,
| but they surely know that -- you don't need to get so
| personally frustrated on their behalf. It's just a
| company with a product in a market, and the market is
| never going to be uniform.
| sdoering wrote:
| I couldn't agree more. Given how much frigging hoops I
| had to jump through to get my Obsidian over syncthing
| setup to sync with my company iPhone - I nearly gave up.
|
| I grew up when computers didn't babysit me and tried to
| act like the good old GDR, knowing every thing better
| than their citicens.
|
| Nowadays, I feel more and more hindered by computers, not
| enabled. Computers used to be a production device (I
| could create things with them).
|
| Phones are not a computer - phones are a just "consume
| like we want you to" device.
|
| The problem is, I want my phone to be a creation device.
| A device that allows me to create content, text, to do
| lists, shopping lists, ideas and store them. And(!) sync
| them using the tools I decide to use. And not force me to
| use tools I friggin hate, because they just don't get the
| job done.
| Philpax wrote:
| How did you get iPhone Syncthing + Obsidian working? I
| was under the impression that it was basically impossible
| to share Mobius Sync's directory with Obsidian.
| aborsy wrote:
| There is a new app Synctrain which does this.
| skydhash wrote:
| I gave up. My phone now is just a communication and
| utility device, and thus I don't feel the urge to upgrade
| until it can't do those tasks. I went back to computers
| (and Linux) to be able to just use them as a computer.
| trav4225 wrote:
| Same. I wish there were an alternative (a practical
| pocket computer), but there really isn't. So I too gave
| up on fighting my phone, and have also completely stopped
| doing mobile development. I now treat my phone
| essentially as an untrusted, prepackaged walled garden
| with limited utility. :-/
| maxboone wrote:
| That's why you can install through F-Droid right?
| sigh_again wrote:
| The java.io.File API isn't removed from Android, nor
| inaccessible. You can absolutely still use it. Google
| Play has chosen to not accept it on their store unless
| you justify it (to their non working bots). In this case,
| the dev chooses to just drop the entire app because
| maintaining it just for Fdroid feels pointless.
|
| There's very few permissions on android that are
| system/privileged/preinstalled.
| growse wrote:
| You don't have root. Google does.
|
| I'm not saying that's a good thing, but it's not exactly
| a secret when you bought it.
| beeflet wrote:
| It's an open-source program, it shouldn't be held to the
| same standards as a closed-source program that just
| shuttles all of your data to someone else's computer.
|
| The risk here isn't misuse of the data, it's that some
| exploit is found in the code, and the additional
| protection of limiting its filesystem access is marginal
| (but nice to have).
| tw04 wrote:
| So Google drive doesn't have full filesystem access
| anymore?
| ants_everywhere wrote:
| > Google took something that solved real problems better
| than any alternative could, did so for many years, and
| destroyed it for no real reason other than to further
| tighten control they have of the supposedly "open"
| platform.
|
| Technically, the guy who inherited Syncthing Android
| maintenance destroyed it because he didn't want to use the
| file permission APIs.
|
| Which, of course, is a reasonable decision for a maintainer
| to make when they're working with limited resources. But I
| have to say in this case I find some of the maintainer's
| behavior to be a bit surprising for a project as mature as
| Syncthing.
| kstrauser wrote:
| Or maybe this, plus Panic removing GDrive support from
| Transmit, plus iA dropping Android support from Writer
| because of it, point to a common perception that Google's
| API for doing things "the right way" suck to the point of
| unusability. If iA and Panic and Syncthing -- all who've
| supported Android for many years -- can't manage to make
| it work, then I suspect it's broken.
|
| Google use to allow just any app to access the whole
| drive. That's probably too permissive. Now they've
| obviously swung too far the other direction, where even
| well intended, experienced devs are unable to work within
| Google's new constraints.
| ants_everywhere wrote:
| I guess I'm a bit at a loss about why these app
| developers feel they need access to things like medical
| records stored on the work phone of everybody at your
| doctor's office.
|
| If they do need access to literally everything on the
| device, then it seems reasonable that they have to pass
| some minimum security bar. After all, several of the apps
| whose data they want access to are used to secure things
| like private medical records, classified information,
| etc.
|
| At some point, the encrypted data has to be mounted as
| plaintext so apps can work with it. It seems reasonable
| to ask for some kind of permission system so that apps
| have to declare they need to read these files and so
| users can make a decision about whether to allow that
| access. But these developers are refusing to even ask for
| that permission.
| kstrauser wrote:
| We both know that first bit is a strawman, so we can move
| past it.
|
| From the description of the people who wrote these apps,
| there are 2 basic APIs at play:
|
| 1. Get access to the entire drive.
|
| 2. Ask for permission to individual files.
|
| I would have assumed there was a middle ground like
| asking for permission to a specific folder's contents,
| yet those same devs insist that's not the case. iA Writer
| users want to edit everything inside a folder. Syncthing
| users want to sync an entire folder. Transmit users want
| to select upload/download to/from an entire folder. If
| Google made those APIs available then we wouldn't be
| having this conversation.
| ants_everywhere wrote:
| > We both know that first bit is a strawman, so we can
| move past it.
|
| Privacy and security are literally the reasons for these
| APIs. I don't see how you could possibly call that a
| strawman.
|
| > I would have assumed there was a middle ground like
| asking for permission to a specific folder's contents,
|
| Isn't that what OPEN_DOCUMENT_TREE does? https://develope
| r.android.com/reference/android/content/Inte...
| kstrauser wrote:
| You're right; my bad. What you said was:
|
| > I guess I'm a bit at a loss about why these app
| developers feel they need access to things like medical
| records stored on the work phone of everybody at your
| doctor's office.
|
| ...which isn't a strawman. It's begging the question by
| presuming that authors actually feel such a need. I'm
| fairly certain the devs involved do not want or care
| about accessing medical records.
|
| As to OPEN_DOCUMENT_TREE, to my naive eyes that's what it
| looks like to me, too. That said, I'm confident that the
| devs we've discussed here, particularly the ones who sell
| the related apps for their livelihood, are clever enough
| to read the docs and that they've ruled it out for some
| reason. I certainly don't think the Syncthing team is too
| incompetent to use a documented method if it magically
| did the right thing.
| ants_everywhere wrote:
| > . It's begging the question by presuming that authors
| actually feel such a need. I'm fairly certain the devs
| involved do not want or care about accessing medical
| records.
|
| iA -- one of the cases you mention -- balked at needing a
| standardized security assessment to access the full
| Google Drive.
|
| > In order to get our users full access to _their_ Google
| Drive on _their_ devices, we now needed to pass a yearly
| CASA (Cloud Application Security Assessment) audit.
|
| https://ia.net/topics/our-android-app-is-frozen-in-
| carbonite
|
| Googe Drive as part of Workspace is HIPAA compliant
| (https://support.google.com/a/answer/3407054?hl=en),
| meaning medical offices can and do host medical records
| on Drive. It's not mentioned in the article why iA needs
| access to all files on a HIPAA compliant service.
|
| Workspace is also (at least partially) FedRAMP compliant
| (https://support.google.com/a/answer/13190816?hl=en). So
| similar questions arise as to whether iA needs to access
| federal data.
| mcherm wrote:
| > for no real reason other than to further tighten control
| they have of the supposedly "open" platform
|
| I think you're overlooking the obvious motivation of
| "maintain a lock on a substantial profit stream".
| toast0 wrote:
| Apple's position is different, because Apple never let you
| have this kind of access.
|
| Android/Google Play review keep restricting APIs and
| replacing them with less capable APIs, or keeping the APIs
| and reducing functionality.
|
| It works again, but I had a USB endoscope that stopped
| working because Google pulled APIs and took a while to
| replace them. I can't use location sharing in my choice of
| apps anymore because something on my phone blocks either app
| runtime, app internet access, app location, or gps decoding
| and I don't use it often enough to be motivated to delve
| through logcat to figure it out, if they even still let me
| use logcat?. I'm sure it helps my battery life, but it
| reduces the functionality of the phone.
| swatcoder wrote:
| There's going to be loud, destructive friction when a 10-15
| year old platform reduces the functionality available to its
| apps. Security models do need to evolve, but Android was
| introduced as a platform suitable for deep personal
| customization with few mandatory boundaries.
|
| This was a competitive distinction against Apple's closed
| "safety first" platform design in iOS and led to an ecosystem
| of applications that took advantage of all these extra
| possibilities. As Google tightens its grip over the platform
| and pursues more aggressive limitations for security reasons
| (and whatever other ones), it's inevitable that many
| publishers and users are going to be deeply frustrated when
| the features that made their device _theirs_ are no longer
| available.
|
| (And incidentally, the restrictions on the Apple side have
| nothing to do with the application development language. I
| don't know where you would get that idea from or how to even
| make sense of it. It's just the nature of Apple's original
| design philosophy for iOS, where apps were deeply isolated
| and had no more capabilities than were necessary. Largely,
| Apple has been gradually _adding_ capabilities to heavily-
| restricted apps over the lifetime of iOS, while Google has
| been moving in the opposite direction because they each
| started from opposite ends of the design space.)
| fny wrote:
| Android is fine. There are many, many complaint syncing
| applications in the wild that use the sanctioned APIs.
|
| The truth is Syncthing doesn't have the resources to keep
| up with Android platform changes and Google's review
| process.
| CorrectHorseBat wrote:
| Why is Android moving so fast?
| growse wrote:
| SAF was first released as part of Android 4.4, back in
| 2013.
| jeroenhd wrote:
| Most changes seem to come down to "the sandbox APIs
| aren't sufficiently isolated, let's lock down the sandbox
| further".
|
| Most file system API changes aren't exactly recent,
| they're just inconvenient. Most changes were introduced
| in Android 11, with some going back all the way to
| Android 4.4. App developers tried to use workarounds,
| exceptions, and special permissions to work around API
| restrictions as long as they could and now the holes in
| the sandbox are finally being closed.
|
| The Syncthing for Android app hasn't had much development
| in the past few years, so years of minor changes have
| added up to tech debt that's (too) expensive to fix.
| beeboobaa3 wrote:
| it's how the cross platform software works and has always
| worked. demanding a total rewrite just to publish on a single
| channel is insane, especially since this used to be the ONLY
| way to do things.
|
| google could always contribute to the open source app to
| implement the features they wish to see, but instead of using
| their billions for good they'd rather use it for evil.
| EasyMark wrote:
| I think burn out on free projects is a real thing. Heck I get
| burn out on old projects and I'm being -paid- to maintain
| them. Good will and accolades only go so far and passion runs
| out eventually, especially if you're only one person and
| there's no one there to give you respite for a good recharge
| and you're facing a hostile entity like Google.
| somat wrote:
| On that note. what is with this modern trend of trying to
| pretend the filesystem does not exist.
|
| why does google(or apple) need "special interfaces" to access
| the filesystem in a specific way, why don't they just use the
| existing file api and improve the file access permission
| system.
|
| I think the unix single tree filesystem was one of their
| great innovations and see this multi tree api fragmentation
| bullshit as a sort of backwards regression.
| pdonis wrote:
| _> what is with this modern trend of trying to pretend the
| filesystem does not exist._
|
| My cynical read is that the filesystem is user freedom, and
| the walled gardens don't want user freedom.
| david_allison wrote:
| Cynical take: it puts Google Drive on a level playing-field
| with local storage (by making the local storage experience
| awful).
| crooked-v wrote:
| For the overwhelming majority of users, the file system is
| a confusing implementation detail that often breaks
| something when they're forced or tricked into directly
| interacting with it.
| lopkeny12ko wrote:
| ...Does the author not understand that the Google Play Store is
| not the only distribution mechanism for apps? Why not just
| continue to distribute APKs for users to install manually?
| gurchik wrote:
| The app is on F-Droid, which is mentioned in the article:
| https://f-droid.org/en/packages/com.nutomic.syncthingandroid...
|
| I'm not sure why it can't continue to be. Does anyone know why?
| somat wrote:
| I suspect it could be, however it sounds like the author has
| lost all motivation to continue work on syncthing android and
| has formally announced that no further development will be
| done. And as much as I like syncthing-android I appreciate
| this sort of straight forward communications more and salute
| the author for clearly stating intentions.
|
| Now seeing as it is open source (hooray) The way I think that
| will go is as follows, we will continue using the existing
| apk(I get mine off f-droid) for a few months to years, in the
| meantime seeing as the app is so useful to so many a few
| forks will arise, one will end up being the best, and we will
| eventually start using that one.
| RussianCow wrote:
| Presumably because most people don't know about F-Droid, and
| there's a question of whether it's worth continuing to
| develop the app for a tiny subset of the original audience.
| suprjami wrote:
| It's stated in the post. They do not think F-Droid provides
| enough distribution because it's not as popular as Google
| Play.
| tomn wrote:
| they do, but google play is the main distribution channel for
| android apps, and without that many people will not use it (and
| many will complain). from the actual announcement:
|
| > without Play releases I do no longer see enough benefit
| and/or have enough motivation to keep up the ongoing
| maintenance
|
| https://forum.syncthing.net/t/discontinuing-syncthing-androi...
| EasyMark wrote:
| They do set how permissions on upgrades of Android work so even
| if it's on f-droid, when they enforce the SAF protocols fsync
| will stop working if you keep your Android up to date
| _fat_santa wrote:
| Looking at the underlying thread[1], the author mentions that
| it's very hard to publish on Google Play
|
| > Reason is a combination of Google making Play publishing
| something between hard and impossible
|
| Can someone expand on what's going on here?
|
| [1]: https://forum.syncthing.net/t/discontinuing-syncthing-
| androi...
| binkHN wrote:
| While I don't know about this developer's specific issues, I
| can comment on my own issues with Google Play as an Android
| developer. Google Play continues to become more and more
| stringent with app permissions and the approval of these
| permissions is very vague. With my own app, from one minor
| release the next, one day I'll receive approval for my app's
| permissions and the next week I will not even though only minor
| changes to the app have been made. When I reach out to Google
| Play support, the answers are always extremely vague, canned
| and repetitive and I never know if an update to my app will get
| approval or not. It's a horrible way to develop anything.
| 1over137 wrote:
| Sounds just like Apple's stores!
| lawgimenez wrote:
| The most annoying requirement is their Play Store delete
| account url. We have an API where we can delete the user's
| account. But no, Google wanted a stupid url.
| macintux wrote:
| Is that so that users who no longer have/want to use the
| app can still delete their account?
| spankalee wrote:
| How do users use the API?
| bmicraft wrote:
| Is it really that hard to set up a small proxy tool that
| calls your fancy api when it receives those requests? As an
| outsider, it does seem quite reasonable to me - Google
| couldn't possibly support all APIs there may possibly exist
| for every app there is.
| beeboobaa3 wrote:
| how are you going to authenticate the user? now you need
| to solve that if you didn't have a web login before.
|
| ---
|
| Guess @dang decided to rate limit my account again so I
| can't post replies :-)
|
| > Some token that every account gets generated? It's
| really not that much to ask honestly.
|
| How is the user going to know this token when they visit
| the website on their laptop? Keep in mind that the Google
| requirement is that you link to this delete page from the
| play store, where the user is _not_ authenticated with
| your app. You can 't just generate an URL containing this
| token.
| bmicraft wrote:
| Some token that every account gets generated? It's really
| not that much to ask honestly.
| mkl wrote:
| > Guess @dang decided to rate limit my account again so I
| can't post replies :-)
|
| There are automatic rate limits that apply to everyone.
| IME you can still click on the comment's timestamp to be
| able to reply.
| izacus wrote:
| In this case the author doesn't want to use Storage Access
| Framework APIs to access the file system which were mandated a
| few years ago as the way to access data outside the app
| sandbox.
|
| They're Java-only APIs and since Syncthings core isn't written
| in Java, the author would have to write JNI glue to call
| Android when writing/reading files (and honestly this would be
| quite tedious, because the way SAF works is to assign Uris to
| each file and you need to keep querying it to get folder
| structure since you can't just concat paths like with files).
|
| The author didn't want to do that and tried to persuade Google
| to continue letting them access all files, all photos and all
| documents directly and Google said no. That was the
| "difficulty" - turns out it's really hard to publish on Play if
| you refuse to follow the guidelines. Just like on AppStore.
| pjmlp wrote:
| Many folks keep thinking that just because Android uses the
| Linux kernel, it is supposed to behave like GNU/Linux.
|
| Likewise they will be rather surprised to insist in targeting
| iOS/iPadOS/watchOS as if they are UNIX clones.
| bmicraft wrote:
| Android being linux has exactly nothing to do with the fact
| that apps can't access resources outside their sandbox if
| they aren't mapped in somehow. Just like with lxc or docker
| containers on linux, jails on *bsd, or any other sandboxes.
| pjmlp wrote:
| The only Linux thing on Android is the kernel, use
| anything else at your peril regarding portability between
| updates and OEM custom forks.
|
| https://developer.android.com/ndk/guides/stable_apis
| bmicraft wrote:
| The only linux thing is always the kernel. Userspace
| isn't linux by definition on any* system. That might seem
| like a pedantic point to make, but I would like to point
| out that gnu utils aren't required to make a system
| "Linux", and whether you're using a drop-in replacement
| like uutils or go a more different route doesn't make it
| any less "Linux".
|
| Android Apps are and mostly always have been restricted
| to the Java virtual machine (or its modern equivalent)
| exactly because that makes them portable between
| sometimes quite different base systems from different
| vendors. If you insist that makes it less of a Linux
| system I'd like to know what you think of flatpak apps on
| top of immutable distros. I hope you agree that,
| conceptually, they're quite close actually.
| pjmlp wrote:
| It certainly makes it less Linux, as most people mean
| Linux kernel plus GNU userspace with glibc, or possibly
| muslc as alternative to glibc.
|
| Nothing of that is expected to be supported on NDK, at
| least officially, Google and partners have the freedom to
| break those expectations as much as they feel like it.
| beeboobaa3 wrote:
| The point is you can't use the regular filesystem
| syscalls on android, it has to go through a weird java
| layer
| scottbez1 wrote:
| And perhaps more to the point - you USED to be able to
| use normal Java file apis and syscalls outside of Java,
| but that functionality has been gradually whittled away
| (in the name of legitimate security improvement) over the
| years, meaning "basic" IO functionality your apps relied
| upon could be taken away at any point and replaced by
| less ergonomic Java-only APIs with less functionality.
|
| Fun fact: the official Dropbox Android app used to use
| inotify to watch for changes to the publicly writeable
| synced files in order to sync back to the cloud! Had to
| be replaced by java Storage Access Framework APIs later.
|
| Another fun fact is that the Android sdk came with a JNI
| wrapper around inotify but it buggily stored inotify
| handles in a static (global, within an app vm)
| dictionary, meaning you'd silently lose tracking if you
| created more than one Java file watcher object that
| happened to be for the same path, so I had to rewrite
| that JNI wrapper back in the day to avoid that global
| state bug.
| josephcsible wrote:
| But it _does_ behave like GNU /Linux where it matters,
| other than Google's arbitrary restrictions.
| treyd wrote:
| To be fair, it's really messy to do Go on Android calling
| back into Java because of how its runtime works. I'm not
| surprised they don't want to do it if it's a hobby project
| and it'd require making substantial changes to Syncthing's
| core logic.
| izacus wrote:
| It is - the way I always structured our architecture in
| this case was to write as much as possible of file handling
| in Java side and keep JNI surface minimal (it's also better
| for performance).
|
| But that's really hard to do if you didn't begin with cross
| platform architecture that doesn't take into account having
| to modularize the filesystem layer for Android/iOS :/
| beeboobaa3 wrote:
| Since you have such strong opinions on the matter, and
| experience, why don't you contribute to the SyncThing
| android app and implement this? Alternatively you could
| grab your time machine, travel back several years and let
| them know to anticipate this arbitrary change google
| would pull in the future.
| refulgentis wrote:
| > (aggro question)
|
| I think it's because he doesn't have a time machine and
| doesn't have time to donate to rewrite someone else's
| project that the owner expressly doesn't want rewritten.
|
| n.b. it wasn't arbitrary
| beeboobaa3 wrote:
| > (snarky response)
|
| This is what we call "Put up or shut up". It's easy to
| bash someone for not wanting to spend many hours of their
| time to work they have no interest in, just because some
| third party is now demanding it. The change is absolutely
| arbitrary, also. There used to be no way to grant apps
| access to specific folders. This is when the app was
| written. This still works. Google's own apps work that
| way. But now Google has also implemented additional ways
| to access the filesystem, and they are demanding people
| who don't even work for them to rewrite their projects.
|
| It would be understandable if they demanded _new_ apps to
| adhere to these new policies. But blocking older apps,
| that were written when there literally wasn 't an
| alternative available, to do a full rewrite or be banned
| from updating? Absurd.
| refulgentis wrote:
| > (snarky response)
|
| If you are now claiming your question was rhetorical, it
| doesn't mean that when answered, it is snark.
|
| > It's easy to bash someone
|
| No one's being bashed. Lets put it in stark relief.
| Here's the bashing you replied to: "But that's really
| hard to do if you didn't begin with cross platform
| architecture that doesn't take into account having to
| modularize the filesystem layer for Android/iOS :/"
|
| > The change is absolutely arbitrary
|
| No, it isn't.
|
| We can tell you know that, because you immediately say
| "There used to be no way to grant apps access to specific
| folders."
|
| > But now
|
| "Now" == "3 years ago"
|
| > demanding people who don't even work for them to
| rewrite their projects
|
| They're not demanding anything, other than Google
| demanding Google can't keep taking updates to an app they
| put on their store, with full filesystem access, _3 years
| later_ , unless they patch the filesystem access. As
| other comments note, there's plenty of storefronts for
| these situations.
|
| n.b. it's dangerous to take updates with unpatched
| security flaws, because bad actors buy apps/browser
| extensions. This is roughly the minimal action Google
| needs to take to avoid being liable - it's been 3 years,
| it looks like complicity to claim its store is safe and
| secure, then repeatedly take updates to products on the
| store with known security vulnerabilities, for years.
|
| > But blocking older apps, that were written when there
| literally wasn't an alternative available, to do a full
| rewrite or be banned from updating
|
| Though interpretative charity, I'm guessing you mean
| Google won't put updates from the vendor on the store,
| unless the update includes stopping asking for full
| filesystem access with 0 alternatives.
|
| > to do a full rewrite
|
| No ones demanding this
| codethief wrote:
| Wait, I seem to remember this discussion from years ago and
| thought it was resolved. Back then, Google wanted to drop the
| "access all files" permission from Android's permission
| system entirely but IIRC Syncthing & file manager devs then
| convinced them to keep it. But now Google comes back at them
| with a Google Play policy that prevents them from using that
| permission in practice?
| IshKebab wrote:
| You have to ask permission via a form from Google and your
| app must closely fit a white list of use cases (file
| manager, etc.) Obviously there's a high chance they just
| say "nah". Definitely sucks.
| fph wrote:
| To be fair, you're making the most used mobile operating
| system in the world and can't be bothered to make API
| bindings for more than one language? Or at least make the
| process easy so that someone else creates them? I am not an
| Android developer, but that seems also part of the problem.
| creshal wrote:
| Yeah, Android has an immense churn of very low quality APIs
| with spotty support outside JVM languages and worse
| documentation.
|
| Combine that with the fact that Android users are
| magnitudes less willing to fund apps (either by buying them
| or donating), and the result is an abysmal ecosystem that
| does not reward continued participation in it.
| pjmlp wrote:
| Android has two official languages for userspace Java and
| Kotlin.
|
| NDK is only for writing native methods, reuse C and C++
| libraries, and better performance for 3D and real time
| audio.
|
| Anything else, is not officially supported by the Android
| team.
| ihuman wrote:
| > They're Java-only APIs and since Syncthings core isn't
| written in Java, the author would have to write JNI glue to
| call Android when writing/reading files
|
| Syncthing-android is already written in Java, so shouldn't
| there already be JNI glue code?
| https://github.com/syncthing/syncthing-android
| zo1 wrote:
| I've done a few apps as part of my day job. And my best
| explanation and/or analogy is government regulations. The store
| requirements, apis and rules are documented up to the upteenth
| degree in 49 pages spread across many areas, and unless you're
| "in the know", you have no way to implement it to a reliable
| degree. And then all this ends up doing is punishing small /
| low-budget / low-time developers, leading to consolidation
| around the big players.
|
| The big players can push their weight around to some degree,
| they get an element of built-in trust, and they have the sheer
| budget/time to implement all the ridiculous and sometimes
| onerous requirements. All in all, they're cementing their
| market position and trying to make "sticky" and invested
| players that will prop-up the play store for the coming
| decades.
| sdoering wrote:
| This is the best analogy I have yet read. It perfectly sums
| up my experience.
| tbrownaw wrote:
| Regulatory capture for fun and profit!
| j1elo wrote:
| What the heck, I literally come from upvoting another
| submission's comment about combining LocalSend with Syncthing
| [1], because the idea seemed great...
|
| That's gone very fast from "oh yeah!" to "oh no!"
|
| [1]: https://news.ycombinator.com/item?id=41891983
| ensignavenger wrote:
| There is a fork mentioned above.
| xnx wrote:
| This is disappointing. SyncThing is one of my reasons for picking
| Android over iPhone. I hope the author reconsidered. Would any
| GoFundMe-style donation goal make the hassle worthwhile?
| exabyte wrote:
| One of the top comments has a link to a fork in case you
| haven't seen it
| andreldm wrote:
| When I migrated from Android to iPhone, syncthing was my main
| pain point. There is Mobius Sync, even though not open source,
| at least it's an one-time small payment, which is fair
| considering the dev license cost. Unfortunately it's not as
| reliable as the Android official app or the fork, I guess Apple
| is very strict with background processing, but hey it's better
| than nothing.
| voltaireodactyl wrote:
| Just discovered the synctrain iOS beta which is extremely
| promising.
| atmosx wrote:
| I'm using Syncthing to sync documents between devices and I own
| a mac fleet and an iPhone. The Mobius Sync[1] client (no
| affiliation) works great for me.
|
| [1] https://mobiussync.com/
| warble wrote:
| It works, and well, considering the constraints in iOS, but
| doesn't compare well with Androids version. Regular sync
| thing on Mac is awesome.
| analog31 wrote:
| Well, I'll be putting the APK in a safe place, along with my
| Turbo Pascal floppies. ;-) Syncthing for Android has been vital
| to managing my sheet music collection.
| 1over137 wrote:
| Is Google treating Dropbox the same way? Sounds like it could be
| anticompetitive behaviour.
| izacus wrote:
| No, because Dropbox actually follows the API guidelines.
| rkagerer wrote:
| How about DropSync (which I find much more useful than the
| official app)?
| izacus wrote:
| I'm afraid I don't know, never used that app.
| Groxx wrote:
| It also uses the scoped storage APIs, it's under no threat.
|
| And +1 dropsync/autosync is phenomenal, it's one of the few
| "basically perfect" apps in my list. Set it and forget it
| for years and zero issues ever.
| hu3 wrote:
| Welp, there goes this recommendation out the window. Back to
| suggesting Dropbox.
| krick wrote:
| That's just great. It's literally the only use case I had for it.
| There are tons of better ways to share files on PC.
| themoonisachees wrote:
| Do give KDE connect a try. It's great
| krick wrote:
| I did, before syncthing. It... isn't great.
| blooalien wrote:
| KDE Connect _is_ great, but _not_ for this use-case.
| SyncThing was absolutely _the_ choice for automated syncing
| of files between Android and PC. KDE Connect just doesn 't
| do that (AFAIK). The two tools serve pretty different
| purposes.
| krick wrote:
| KDE Connect wasn't really reliable and easy to use while
| I did. And Syncthing pretty much eliminated the need to
| use KDE Connect for me. The only extra-feature of KDE
| Connect was sharing the buffer, and I just paste to
| Obsidian now instead (any text editor would do, but I
| don't know anything better, even though I hate it for
| being closed-source). Maybe slightly less ergonomic than
| KDE Connect in this regard, but it's negligible. And I
| don't need to send files, if I can just share files.
|
| In fact, I think I never even connected the phone via USB
| since I started using Syncthing. Copying/moving to/from
| shared folder is amazingly both more ergonomic and much
| faster (I never learned, why moving files to Android
| device via USB is so insanely slow).
|
| So I really don't know an alternative. It solved pretty
| much all my phone/PC sync needs. It also enables
| backuping the important stuff (I don't use Google for
| that, or course). Dropbox doesn't cut it either. I really
| don't imagine how would I use my phone w/o Syncthing,
| it's pretty much essential.
| raffraffraff wrote:
| I run KDE on my "TV" and the media controls and clipboard
| sharing are worth it. I occasionally use my phone as a
| trackpad too.
| bmicraft wrote:
| Sharing files? Probably. Reliably syncing files without
| interaction, and especially without requiring a central server?
| i don't think so.
|
| The truth is, the android app has existed for over 10 years now
| and it has never been good. It kinda mostly worked for some use
| cases, but always-on continuous sync on battery wasn't really
| one of them. And that's been true even before Google
| justifiably started restricting filesystem access in KitKat(!)
| 11 years ago.
|
| If you are looking for an Android app that does syncing in the
| background well, I can highly recommend FolderSync.
| akvadrako wrote:
| FolderSync with which protocol?
|
| The main reason I use Syncthing is not to use Dropbox for
| sensitive stuff, which I also use since it's on-demand mobile
| sync is way better.
| bmicraft wrote:
| SFTP or SMB depending on your computer/server I guess, or
| any of the supported cloud options of which there are truly
| plenty. I'm using SFTP for everything.
|
| FolderSync can do "on-demand" very well if you mean that
| you just want to tap a sync button to trigger it.
| akvadrako wrote:
| By on-demand I mean per file or folder. So a virtual
| filesytem that downloads as needed.
| pomian wrote:
| I would think that a user competent to use and want sync thing,
| is perfectly capable of depending on f droid as a source for the
| apk. Can that not be enough of a distribution channel.
| KetoManx64 wrote:
| I guess we will find out in the next couple of months as people
| either migrate to the F-Droid based "syncthing-fork" or move to
| a different sync tool.
| denismi wrote:
| Without Android what's even the point? If all I have is laptop
| and desktop, I probably just run scheduled rsyncs or a systemd
| timer something.
| EasyMark wrote:
| You can run that on android? Sorry I've been out of the android
| world for a while :)
| meowster wrote:
| Does anyone have any other opensource recommendations?
| timetraveller26 wrote:
| rsync or rclone on termux
| beeflet wrote:
| that would require you to set up a domain name and use DDNS
| and trust your registrar, or to just always have your
| computers at a static IP with no NAT blocking you whatsoever.
| wazzaps wrote:
| Or use Tailscale to solve both issues at once
| jlokier wrote:
| I tried Termux and found the application files I wanted to
| rsync aren't visible in Termux, except maybe by rooting the
| phone. But I need to use banking and auth apps daily on it,
| so I assume that isn't an option.
| donatzsky wrote:
| There's a fork called, rather creatively, Syncthing-Fork. It's
| available on F-Droid.
| warble wrote:
| This one is way more battery conscious as well. Works great,
| I prefer it.
| sunshine-o wrote:
| I have heard good things about git-annex [0]
|
| But don't expect the same polished user experience as with
| SyncThings
|
| - [0] https://git-annex.branchable.com/Android/
| havaloc wrote:
| Joining the IA Writer club on Android:
| https://news.ycombinator.com/item?id=41658023
| clot27 wrote:
| Shit, this was the app I used to sync my obsidian notes through
| multiple devices.
| onehair wrote:
| Keepass and logseq for me
| clot27 wrote:
| Shit, this is the app I use to sync my obsidian notes through
| multiple devices. R.I.P.
| dang wrote:
| Url changed from
| https://old.reddit.com/r/Syncthing/comments/1g7zpvm/syncthin...,
| which points to this.
|
| Submitters: " _Please submit the original source. If a post
| reports on something found on another site, submit the latter._ "
| - https://news.ycombinator.com/newsguidelines.html
| Symbiote wrote:
| Does anyone know how long I could expect the current Syncthing
| Android app to continue working?
| suprjami wrote:
| Please read the article before commenting. It is clearly
| stated.
| yjftsjthsd-h wrote:
| Is it? I see
|
| > The last release on Github and F-Droid will happen with the
| December 2024 Syncthing version.
|
| but not even a hint as to whether that APK is likely to work
| in say 2027.
| Groxx wrote:
| The app will work until Google decides to remove APIs it
| uses, which hasn't been put on a roadmap yet AFAIK.
|
| This is just removing it from the play store, which is much
| picker about API use than the OS. The APK will continue to
| exist and run fine (though not developed, try a fork).
| rcarmo wrote:
| I hope it can live on inside F-Droid somehow.
| redleader55 wrote:
| It can be hosted in any app store, but because it doesn't use
| the correct APIs - according to Google - it will not work on
| newer Android devices.
| david_allison wrote:
| AFAIK, it's fine on later devices, but Google Play
| specifically restricts the permission which they need
| (`MANAGE_EXTERNAL_STORAGE`)
| thenoblesunfish wrote:
| That's a bummer! Can anyone suggest an alternative way I can get
| files from my macOS laptop to my Android phone? I "just" want to
| put my folder of music files and m3us there so I can play them
| (with PowerAmp).
| momo777 wrote:
| Localsend
| eternityforest wrote:
| Syncthing-fork from f droid
| treve wrote:
| Eek. That's how I get my keepass database on my phone. Anyone
| else in this predicament?
| cja wrote:
| Likewise
| fuster wrote:
| Keepass and Joplin.
| replete wrote:
| Resilio Sync is pretty good although proprietary
| Groxx wrote:
| syncthing-fork has been working noticeably better for me for a
| couple years now:
| https://f-droid.org/en/packages/com.github.catfriend1.syncth...
| lgbr wrote:
| The KeePass2Android app gains a bit of functionality if you use
| it with SFTP instead. You get the ability to, for example,
| merge changes in the event that there's a conflict. I recommend
| using SFTP to a machine that then runs SyncThing to the rest of
| your devices.
| ethagnawl wrote:
| Re merges: that's very compelling. I've encountered that
| issue many times using Dropbox for syncing.
| butz wrote:
| Thank you google for killing yet another great app. There should
| be special category for apps that are "Done, Complete, Perfect as
| is", as with decent backwards compatibility on Android there
| should be no issues with them. I bet apk compiled for Android 1
| still runs perfectly on Android 15.
| eternityforest wrote:
| Android is one of the few platforms on earth where anything
| interesting actually could be done and finished, since they
| have actual stable API levels unlike Linux.... And they don't
| allow it
| Izkata wrote:
| Depends on the exact functionality. I'm aware of some battery
| events you could listen to from the manifest file in 2, that
| were removed at some point after that and now you have to
| listen for them from a running service. It broke a bunch of
| battery monitoring apps when it happened.
|
| Also with services, there's additional requirements to keep
| them running that weren't there early on.
| eternityforest wrote:
| If the Catfriend fork goes, I'll have no use for Syncthing at
| all, and it will be a very sad day in open source. I'll probably
| move to some proprietary app, since I'm definitely not interested
| in self hosting anything, and there's not really any FOSS
| equivalents other than Syncthing itself.
|
| Android really needs to just allow direct file access to any file
| which is under a user selected folder.
| nixosbestos wrote:
| > Android really needs to just allow direct file access to any
| file which is under a user selected folder.
|
| It does.
|
| Edit: downvotes don't change the reality that I am using
| SyncThing-Fork with no Storage permission granted to it. It's
| the very fucking feature this entire thread is about
|
| Take the downvote button away from imbeciles. Or make voting
| public, god that would solve so many problems.
| david_allison wrote:
| >> Android really needs to just allow direct file access to
| any file which is under a user selected folder.
|
| > It does.
|
| No it doesn't, `ACTION_OPEN_DOCUMENT_TREE` provides you with
| a `DocumentFile`, which isn't a `java.io.File`.
|
| From their docs:
|
| > It offers a simplified view of a tree of documents, but it
| has substantial overhead
|
| https://developer.android.com/reference/androidx/documentfil.
| ..
|
| ----
|
| Your fork uses `MANAGE_EXTERNAL_STORAGE` which Google Play
| heavily restricts:
|
| https://github.com/Catfriend1/syncthing-
| android/blob/main/ap...
|
| This is very likely the reason that your fork no longer
| wishes to be on the Play Store:
|
| > Planning to close my Google Play Developer Account. Please
| say hi if you are interested in obtaining the latest gplay
| release files from me to help in publishing this app.
|
| https://github.com/Catfriend1/syncthing-
| android?tab=readme-o...
|
| EDIT: The dangerous permission for `MANAGE_EXTERNAL_STORAGE`
| doesn't appear in the "App Info", which may be what you're
| seeing.
| solarkraft wrote:
| Syncthing is essential for syncing some very important data for
| me. I'd be so disappointed if it was discontinued for the
| platform I use.
| dod9er wrote:
| Once again, Im also in the niche of avoiding pay-for dozens of
| small services and just getting my simple stuff synced. Bam,
| another blowback. Im eager to ready what alternatives HN crowd
| might come up with....
| andyjohnson0 wrote:
| I'm a big fan of Syncthing, and use it on Android as well as pc.
| But it seems they are relying MANAGE_EXTERNAL_STORAGE permission
| and I can't see a good reason for Google to go on permitting that
| in 2024. It gives an app too much power.
|
| Android has had scoped storage for a decade now. Time to get with
| the program and start using the SAF.
|
| It does feel very odd to be actually agreeing with the Goog on
| something...
| bakugo wrote:
| An app that's supposed to sync your files having access to your
| files is "too much power" now?
|
| It's hard to fathom just how much damage smartphones have done
| to personal computing, but statements like these are a grim
| reminder.
| amelius wrote:
| I hate mobile computing so much.
| RadiozRadioz wrote:
| I've been considering making a new Android app for a while. A
| simple one to interact with a couple of my web services with some
| on-device storage, nothing complicated. More than anything, the
| thing that's stopping me is that I _know_ if I make it, a few
| Android versions later, it either won't work or won't be allowed
| on Play. I can't predict what random piece of the Android
| API/policy will change, but I know something will. And I'll have
| to waste my time fixing something that worked fine until Google
| arbitrarily broke it.
|
| I built one app before for JellyBean. I haven't been able to
| install it for years and I can't compile it for a new version
| because of a cascade of errors and required changes that I'm
| unwilling to do. JellyBean hadn't even reached 10 years old
| before my app broke, it's pathetic that app support crumbled and
| rotted away that quickly. It'll happen again, so I've been turned
| off of Android development.
|
| I totally understand the discontentment. It makes you feel
| powerless.
| eightys3v3n wrote:
| Thank you for your work. I'm sorry to see you go. I really hope
| Syncthing continues to have a presence on Android.
| scottbez1 wrote:
| I used to develop Android professionally (at Dropbox in the
| 2010s, so I have some familiarity with older Android filesystem
| APIs) and made a very conscious decision to switch to devx and
| backend work and get out of Android (as did most of my former
| Android colleagues). The unending hoops you had to jump through
| and API changes to keep your app working were too much of a pain.
|
| As a fun anecdote, in 2014 when the "secure" Storage Access
| Framework was new, I found a trivial directory traversal vuln
| that allowed writing to any app's private directory by just
| passing a "../../" file name to the system [0, 1]. It was so
| trivial I noticed it while just browsing AOSP source to
| understand SAF better...
|
| Android also used to grant world execute bits to app folders for
| the longest time, allowing malicious apps to create hard links to
| other apps' files by name, which could then be handed back to
| that app for a confused-deputy attack to gain access to the file
| contents.
|
| All that to say - I'm glad Android has been working on security,
| but it was built upon such a loose foundation that tons of apps
| used and abused that it's going to drive developers out of the
| ecosystem as they have to keep adapting to a continuous stream of
| major breaking changes as things are locked down.
|
| [0] Bug 18512473 fixed in
| https://android.googlesource.com/platform/frameworks/base/+/...
|
| [1] Proof of concept video:
| https://www.dropbox.com/s/8dpd8visrttqbfo/poc.mp4?dl=0
| psanford wrote:
| It sucks that the ongoing maintenance cost for the native
| mobile platforms is so high. Who wants to develop on top of a
| platform that is constantly changing out from under you?
|
| It really makes me nostalgic for the vision of webOS (although
| not the implementation of webOS from 14 years ago).
| AStonesThrow wrote:
| I used Syncthing for a while between various Linux distros, and I
| used Syncthing-Fork on my Android tablet, and it was okay when it
| worked, but it often borked up, and there were so many arcane
| settings and weird failure modes. I realized that the only reason
| I was using Syncthing was because it appealed to the vestigial,
| ultra-paranoid crypto-fascist BOFH in me, and I had grown out of
| those attitudes.
|
| So today I just use Google Drive and MS OneDrive like a normal
| person. They work great. I love 'em. They don't fail like
| Syncthing. They're way more secure, and fully supported. Come
| join me! The water's fine!
| Svoka wrote:
| I am developing and supporting game engines for over a dozen
| years. It works pretty much on any device which can run games.
|
| Supporting it for Android is the worst experience ever. This is
| by far the least reliable OS in terms of compatibility or changes
| they make. It gets more convoluted and crapier with every exec
| bonus and 'feature' google invents.
| shwouchk wrote:
| FWIW I use syncthing-fork from f-store and im quite happy with
| it. Development seems kinda slow lately but it's chugging along.
___________________________________________________________________
(page generated 2024-10-20 23:00 UTC)