Ios version of app works, but Android fails due to

问题:

As mentioned in the title, the Ios version of this app works fine on a physical device. However, when I try to build it on an android device, I get an error

error: no suitable constructor found for AccessToken(String,String,String,<null>,<null>,<null>,<null>,<null>)
constructor AccessToken.AccessToken(String,String,String,Collection<String>,Collection<String>,AccessTokenSource,Date,Date,Date) is not applicable
(actual and formal argument lists differ in length)
constructor AccessToken.AccessToken(Parcel) is not applicable
(actual and formal argument lists differ in length)

This error is highlighted in FBGraphRequestModule.java file, specifically in this method

    private void setConfig(GraphRequest graphRequest, ReadableMap configMap) {
            if (configMap == null) {
                graphRequest.setAccessToken(AccessToken.getCurrentAccessToken());
                return;
            }
            if (configMap.hasKey("parameters")) {
                graphRequest.setParameters(buildParameters(configMap.getMap("parameters")));
            }
            if (configMap.hasKey("httpMethod")) {


graphRequest.setHttpMethod(HttpMethod.valueOf(configMap.getString("httpMethod")));
    }
    if (configMap.hasKey("version")) {
        graphRequest.setVersion(configMap.getString("version"));
    }
    if (configMap.hasKey("accessToken")) {
        graphRequest.setAccessToken(new AccessToken(
            configMap.getString("accessToken"),
            AccessToken.getCurrentAccessToken().getApplicationId(),
            AccessToken.getCurrentAccessToken().getUserId(),
            null,
            null,
            null,
            null,
            null));
    } else {
        graphRequest.setAccessToken(AccessToken.getCurrentAccessToken());
    }
}

More specifically,

if (configMap.hasKey("accessToken")) {
            graphRequest.setAccessToken(new AccessToken(
                configMap.getString("accessToken"),
                AccessToken.getCurrentAccessToken().getApplicationId(),
                AccessToken.getCurrentAccessToken().getUserId(),
                null,
                null,
                null,
                null,
                null));

My Java skills are nonexistent, so I have no idea how to fix this problem.

回答1:

I had the same issue today as well, upgrading react-native-fbsdk to 0.8.0 seems to fix it

回答2:

I had also that issue today and solved by modifying the package to have the last parameter - dataAccessExpirationTime.

new AccessToken(
            configMap.getString("accessToken"),
            AccessToken.getCurrentAccessToken().getApplicationId(),
            AccessToken.getCurrentAccessToken().getUserId(),
            null,
            null,
            null,
            null,
            null,
            null)

You will see this issue in FBGraphRequestModule.java and Utility.java file. So please fix both files.

回答3:

I had the same issue, my understanding is that react-native-fbsdk v0.7.0 had not locked the minor version of the dependency com.facebook.android:facebook-android-sdk. see compile 'com.facebook.android:facebook-android-sdk:4+' in node_modules/react-native-fbsdk/android/. Facebook released a new version 4.38.1, previously known working version was 4.37.0. Because the minor version was not locked the newer version of com.facebook.android:facebook-android-sdk:4 was pulled down and caused breakage.

Upgrading to react-native-fbsdk v0.8.0 and com.facebook.android:facebook-android-sdk:4.38.1 changes the binary package, forcing us to do a full app update ( opposed to just a UI content updated via Code-Push ). We try to limit binary releases because they're larger and our users aren't forced to update the app.

Force resolving the version of com.facebook.android:facebook-android-sdk:4+ worked for us

In the root build.gradle file add or merge the following

allprojects {
    configurations.all {
        resolutionStrategy {
            force 'com.facebook.android:facebook-android-sdk:4.37.0'
        }
    }
}

Ref : This article describes some of the downsides to having dynamic dependancies. I suggest when you include a new module lock all the dynamic dependancies. This will help ensure every rebuild results in a predictable output.