SDK 34 Play Store Rejected without video of FOREGROUND_SERVICE_DATA_SYNC functionality

[baggednismo]

Describe the bug The library has been fully functional and setup as documented. Has been working in production for months now. Targeted the latest SDK 34 when building for release. After uploading to google play console it throws an error You must let us know whether your app uses any Foreground Service permissions.

Looking through the manifest merge logs I found this ADDED from [net.gotev:uploadservice:4.9.2] /Users/{user}/.gradle/caches/transforms-3/79699670084e687319315e25462d08d3/transformed/jetified-uploadservice-4.9.2/AndroidManifest.xml:8:22-74 uses-permission#android.permission.FOREGROUND_SERVICE_DATA_SYNC

Using this library now requires videos to be taken of the upload process in order to release it.

To Reproduce

1. Set target / compile SDK to 34
2. Upload to Google Play console as a new release.

Screenshots

[gotev]

Thank you, useful to be known!

[trix0]

@baggednismo I am currently in a process to upgrade our apps for SDK 34 and originally came looking if DATA_SYNC will be good enough for this.

Did your app manage to get through the process after you uploaded the video?

[baggednismo]

@trix0 I didn't want to take the chance, I had a critical project that needed to move to production. I removed the library and switched to workmanager.

[swizes]

we are also actively using this library and with provided video of upload feature our app has been approved.

[sublime392]

edit: I see this has been addressed, and it doesn't look super good for this lib: https://github.com/gotev/android-upload-service/issues/610#issue-1045256189

Are there any plans to change this to use workmanager?

Using FOREGROUND_SERVICE_DATA_SYNC is not allowed unless the user is not directly interacting with the app during the upload. I don't think typical uses will qualify, hence the video requirement because Google doesn't think most use cases will qualify either.

Even if it gets through once, it would be a risk because a year from now you might be trying to patch a bug and then get rejected because the new reviewer does not agree with how FOREGROUND_SERVICE_DATA_SYNC is being used.

[gotev]

@sublime392 in #610 I still haven't got any other thought about my reasoning, nor contributors wanting to help. Currently I don't have time for a rewrite. Re-opened it so it gains some visibility.

[linean]

Despite providing an explanatory video, Google has rejected my app update saying:

Specifically, the declared use case(s) can be interrupted or deferred by the system without creating a negative user experience. Your app is using foreground service to Data Sync - Other when it is not required to do so.

It seems the only solution is to migrate to a different lib 😞

[gotev]

@linean if you're using only the bundled-in Binary and Multipart upload protocols of the lib, you can make a point that they do not support resume, so you have to start the uploads over in case of any interruptions, leading to poor UX and higher network and battery usage. This is one of the major points in favor of keeping the service architecture and also common knowledge, specified in the respective RFCs and also documented in the wiki: https://github.com/gotev/android-upload-service/wiki/4.x-Usage#http-multipartform-data-upload--rfc2388 but it's better to let Google reviewers know, as they may assume you're using a resumable upload protocol.

[linean]

Thanks, that's a great suggestion! I'll consider this option.

[gotev]

@linean I don't know the specifics of your use case, but for anyone reading this, if your app is made for field operations or you need fast and instant uploads, which are critical for your use case, let Google reviewers know, together with the specifics I mentioned about binary and multipart upload protocols in my previous comment.

[senryakuka]

Hi last month i'm updating my app to comply with the play store request and this problem also occured to me, i make a video where the the library is used and google approved it