We are aware of the issue with the badge emails resending to everyone, we apologise for the inconvenience - learn more here.
Forum Discussion
Updating a very old app to Java SDK 7.0.0
In preparation for the 2026 deadline on updating my Android app to the Dropbox 7.0.0 Java SDK, I changed the dependencies from the very old dropbox-core-sdk:3.1.5 to:
implementation 'com.dropbox.core:dropbox-core-sdk:7.0.0' implementation 'com.dropbox.core:dropbox-android-sdk:7.0.0'
Plus I added this, although I'm not sure if it is needed since my app is just JAVA, not Kotlin:
implementation 'org.jetbrains.kotlin:kotlin-stdlib:1.6.21'
With the user tap on a button, my code launches the OAuth v2 process:
List<String> scope = new ArrayList<>(Arrays.asList("files.content.write", "files.content.read")); Auth.startOAuth2PKCE(getApplicationContext(), getString(R.string.APP_KEY), requestConfig, scope);
which did invoke the web-based Dropbox sign-in I was familiar with, but upon authorizing my app to access Dropbox, my app threw a java.lang.RuntimeException which I will list later. But it appeared that the exception was caused by: java.lang.NoSuchFieldError: No field Companion of type Lokhttp3/RequestBody$Companion; in class Lokhttp3/RequestBody; or its superclasses
Seeing the reference to HTTP3 in logcat, I remembered that the lastest examples of generating the requestConfig was simply:
requestConfig = DbxRequestConfig.newBuilder("<app name>").build();
Whereas my old code that was causing the crash was:
DbxRequestConfig.newBuilder("<app name>").withHttpRequestor(new OkHttp3Requestor(OkHttp3Requestor.defaultOkHttpClient())).build();
When I switched over to using the simpler requestConfig, everything worked. My app connected to Dropbox and did a file transfer as usual. Since my code is so old, I have no idea why I had that extra step involving OkHttp3Requestor. Can anyone enlighten me as to why the extra code was in there in the first place? Will this code continue to work without it?
As promised, here is the logcat dump of the runtime exception, although it is less relevant now that the crash has been avoided:
FATAL EXCEPTION: AsyncTask #1
Process: com.xxxxxxx.xxxxx, PID: 6214
java.lang.RuntimeException: An error occurred while executing doInBackground()
at android.os.AsyncTask$4.done(AsyncTask.java:415)
at java.util.concurrent.FutureTask.finishCompletion(FutureTask.java:383)
at java.util.concurrent.FutureTask.setException(FutureTask.java:252)
at java.util.concurrent.FutureTask.run(FutureTask.java:271)
at android.os.AsyncTask$SerialExecutor$1.run(AsyncTask.java:305)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
at java.lang.Thread.run(Thread.java:923)
Caused by: java.lang.NoSuchFieldError: No field Companion of type Lokhttp3/RequestBody$Companion; in class Lokhttp3/RequestBody; or its superclasses (declaration of 'okhttp3.RequestBody' appears in /data/app/~~ZLWBSuvkl8bQpATFtf6zgg==/com.xxxxxxx.xxxx-UGcSd1gkutTnla8xW1LhUA==/base.apk!classes4.dex)
at com.dropbox.core.http.OkHttp3Requestor$BufferedUploader.upload(OkHttp3Requestor.java:231)
at com.dropbox.core.DbxRequestUtil.startPostRaw(DbxRequestUtil.java:278)
at com.dropbox.core.DbxRequestUtil.startPostNoAuth(DbxRequestUtil.java:255)
at com.dropbox.core.DbxRequestUtil$2.run(DbxRequestUtil.java:509)
at com.dropbox.core.DbxRequestUtil.runAndRetry(DbxRequestUtil.java:560)
at com.dropbox.core.DbxRequestUtil.doPostNoAuth(DbxRequestUtil.java:506)
at com.dropbox.core.DbxPKCEManager.makeTokenRequest(DbxPKCEManager.java:115)
at com.dropbox.core.android.internal.TokenRequestAsyncTask.doInBackground(TokenRequestAsyncTask.kt:22)
at com.dropbox.core.android.internal.TokenRequestAsyncTask.doInBackground(TokenRequestAsyncTask.kt:11)
at android.os.AsyncTask$3.call(AsyncTask.java:394)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at android.os.AsyncTask$SerialExecutor$1.run(AsyncTask.java:305)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
at java.lang.Thread.run(Thread.java:923)
The Dropbox Java SDK offers (in both older versions and the current version) the ability to use a custom "requestor" (essentially the network client used to perform the actual network requests to the Dropbox API servers). That enables more control over how the requests are handled.
That's not required though; you can certainly use the default functionality if that works for your use case.
As to why you had that previously, I can't say for sure. You may have previously needed or planned to use OkHttp functionality in particular, or otherwise just happened to write the code based on an OkHttp sample.
- Greg-DB
Dropbox Staff
The Dropbox Java SDK offers (in both older versions and the current version) the ability to use a custom "requestor" (essentially the network client used to perform the actual network requests to the Dropbox API servers). That enables more control over how the requests are handled.
That's not required though; you can certainly use the default functionality if that works for your use case.
As to why you had that previously, I can't say for sure. You may have previously needed or planned to use OkHttp functionality in particular, or otherwise just happened to write the code based on an OkHttp sample.
Additional information: When it crashed I was still linking with an older version of OKHTTP3 (version 3.10.0). When I updated to version 4.12.0, the Dropbox OAuth v2 flow worked fine without a crash. There is no specific functionality in OKHTTP3 that I need, so I may still remove it just to be safe.
About Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
