Targeting S+ (version 31 and above)

[vasudevjogani]

E/JobProxy14: com.app.xyz: Targeting S+ (version 31 and above) requires that one of FLAG_IMMUTABLE or FLAG_MUTABLE be specified when creating a PendingIntent. Strongly consider using FLAG_IMMUTABLE, only use FLAG_MUTABLE if some functionality depends on the PendingIntent being mutable, e.g. if it needs to be used with inline replies or bubbles.

[adimiz1]

Hi @vasudevjogani We plan to release a new major version for the Android SDK by Sunday, If you want to submit a PR for us to review with the change by then we can put it into this release feel free to do so

[isles1217]

Hey there! I'm still seeing these errors on version 2.2.0. Any chance you could revisit this issue? Thanks!

E/JobProxy14: Targeting S+ (version 31 and above) requires that one of FLAG_IMMUTABLE or FLAG_MUTABLE be specified when creating a PendingIntent.
    Strongly consider using FLAG_IMMUTABLE, only use FLAG_MUTABLE if some functionality depends on the PendingIntent being mutable, e.g. if it needs to be used with inline replies or bubbles.
    java.lang.IllegalArgumentException: Targeting S+ (version 31 and above) requires that one of FLAG_IMMUTABLE or FLAG_MUTABLE be specified when creating a PendingIntent.
    Strongly consider using FLAG_IMMUTABLE, only use FLAG_MUTABLE if some functionality depends on the PendingIntent being mutable, e.g. if it needs to be used with inline replies or bubbles.
        at android.app.PendingIntent.checkFlags(PendingIntent.java:375)
        at android.app.PendingIntent.getBroadcastAsUser(PendingIntent.java:645)
        at android.app.PendingIntent.getBroadcast(PendingIntent.java:632)
        at com.evernote.android.job.v14.JobProxy14.getPendingIntent(JobProxy14.java:199)
        at com.evernote.android.job.v14.JobProxy14.cancel(JobProxy14.java:162)
        at com.evernote.android.job.JobProxy$Common.cleanUpOrphanedJob(JobProxy.java:285)
        at com.evernote.android.job.JobManager.schedule(JobManager.java:188)
        at com.evernote.android.job.JobRequest.schedule(JobRequest.java:430)
        at com.cloudinary.android.AndroidJobStrategy.doDispatch(AndroidJobStrategy.java:99)
        at com.cloudinary.android.DefaultRequestDispatcher.dispatch(DefaultRequestDispatcher.java:54)
        at com.cloudinary.android.UploadRequest.doDispatch(UploadRequest.java:245)
        at com.cloudinary.android.UploadRequest.dispatch(UploadRequest.java:202)
        at com.cloudinary.android.UploadRequest.dispatch(UploadRequest.java:170)

[michalkcloudinay]

Hi @isles1217,

Can you please let us know if this is happening when running the sample project? Or when implementing the SDK in your project?

[isles1217]

I'm seeing this error when integrating the SDK into my project. Thanks!

[michalkcloudinay]

Thanks for getting back.

We are unable to reproduce this issue on our end. Can you please provide me with the line in the code that pops this warning? Also, can you please make sure that the build.gradle / pom.xml file is synced after updating the latest version of the Cloudinary SDK? Looking forward to your updates, Thanks Michal

[isles1217]

Hi Michal,

Version 2.2.0 was just integrated into our project and is the first/only version of the SDK, so my build.gradle file is definitely up-to-date. Based on the stacktrace, I'm guessing the issue is that the Cloudinary SDK seems to be using Evernote's Deprecated JobManager SDK, which, according to its own Github readme, shouldn't be used anymore. Are you able to estimate how long it might take to migrate to WorkManager instead?

Here's the calling code:

            MediaManager.get()
                .upload(fileUri)
                .options(options)
                .callback(
                    object : UploadCallback {
                        override fun onStart(requestId: String?) {
                            (...)
                        }

                        override fun onProgress(requestId: String?, bytes: Long, totalBytes: Long) {
                            (...)
                        }

                        override fun onSuccess(
                            requestId: String?,
                            resultData: MutableMap<Any?, Any?>?
                        ) {
                            (...)
                        }

                        override fun onError(requestId: String?, error: ErrorInfo?) {
                            (...)
                        }

                        override fun onReschedule(requestId: String?, error: ErrorInfo?) {
                            (...)
                        }
                    }
                )
                .dispatch()

[michalkcloudinay]

Thanks @isles1217 for providing more details. We were now able to reproduce the issue on our end. We will take this internally and keep you updated here with any new information.

Thanks, Michal

[dimaportenko]

Any updates here? I have the same issue.

[dimaportenko]

I think I solved my issue by adding resource_type option

...
      uploadRequest
          .unsigned(presetName)
          .option("resource_type", getResourceType(params.getString("type")))
...

[victorli-cloudinary]

Thanks for the update @dimaportenko. @isles1217 can you try the above?

[isles1217]

@victorli-cloudinary that didn't make a difference. the issue isn't that the upload isn't working, but that it's using deprecated libraries (all which throw a barrage of warnings), and poses a risk that the SDK could break on newer Android OS versions. Any update as to when this will be fixed and when the updated SDK will be available?

[isles1217]

It looks like this issue can be closed. Thanks! 🎉