We are following this guide on setting up adverts with the Facebook SDK on android.
https://www.facebook-studio.com/fbassets/resource/71/MobileAppInstallAds_ProductSetupGuide.pdf
There is a line in there that tells you to add the following to your app:
Facebook fb=new Facebook(appId);
fb.publishInstall(appContext)
However looking through the Facebook SDK code, it appears to send this off automatically when you call authorize (via the autoPublishAsync method).
As we are calling authorize, and it calls through to publishInstall, we have assumed this extra call isn't needed. (Could someone confirm this?)
We have everything working on iOS, which is reporting installs perfectly. However, we aren't seeing as many android installs coming through as we would expect (though we are seeing some - implying it is working to some extent).
While debugging the app, the publishInstall method is called and sends the install to facebook, but the response from that method isn't parsed or validated at all. So presumably it could be failing in production for some reason and we'd never know.
Is there a page somewhere to just view android installs to validate that it is all working correctly on FB's side? Or does anyone have any other suggestions about what might be going wrong, or how to debug this?
Calling Facebook.authorize will transitively also call publishInstall. However, unless you call Facebook.authorize for every user (rather than just when they click on a login button), you may not cover all cases.
You should also update to the new 3.0.1 version of the Android SDK (released last week), which does better response handling/caching for publishInstall requests.
Related
My app uses Google App Engine as backend and it provides google plus & facebook login option to user.
One of the endpoint Api takes user profile picture url as input parameter and tries to store it in the user profile table. My endpoint Api was not getting called successfully when user choose the option of google plus as login,
I have narrowed down the issue to find out that it only happens during google plus login scenario and from the backend logs I see the issue is only because of below parameter which is profile photo url.
https:%2F%2Flh3.googleusercontent.com%2F-xPc6TIzQiFA%2FAAAAAAAAAAI%2FAAAAAAAAAeU%2FUIIpz-4G1dQ%2Fphoto.jpg%3Fsz=400
Backend Request from logs(Data changed for privacy reasons).
/_ah/api/registrationAPI/v2/XXXXXX/Rahul%20Purswani/rahulfhp#gmail.com/https:%2F%2Flh3.googleusercontent.com%2F-xPc6TIzQiFA%2FAAAAAAAAAAI%2FAAAAAAAAAeU%2FUIIpz-4G1dQ%2Fphoto.jpg%3Fsz=400/XXX/YYY/VVV, returning NOBODY to imply authentication is in progress.
My Api Class Declaration :
#Api(name="registrationAPI",
version="v2",
namespace=#ApiNamespace(ownerDomain="backend.XXX.XXX.YY",ownerName="backend.XXX.XXX.YY",packagePath=""))
public class PlayerRegistrationEndPoint {
}
And to my surprise this only happens when I test the Api on local development server through real device. If I deploy my api all works fine, I have spent almost the day to narrow it down, If you have any clue about it that will be really appreciable.
Are you accidentally logging the bytes of your pictures using logging.info(), logging.error(), print, etc? Logging bytes to either the logger or standard out can make the dev instances (or even production instance) go into zombie mode.
This has happened to me many times. Check all logs to make sure you aren't trying to log something that isn't a basic variable type.
I was getting this issue since we migrated our code base from Eclipse to Android Studio, during this migration our app-engine sdk version got changed from 1.9.22 to 1.9.18.
Looking back and doing comparative analysis with why it used to work with eclipse, I tried using 1.9.22 app-engine sdk here and issue got resolved, the zombie behavior is no more and even in development environment everything is stable now.
I also checked & removed all the loggers and out statements, though the issue was not fixed with trying that alone.
Thanks for even letting me know that it can also go wrong in future during development environment testing.
I am working on finishing up an Android app that has been under development for ages. The app uses the Facebook SDK for Android to post a simple link to the users wall after making a selection from a PlacePicker fragment. The SDK was very old and was using v1.0 of the FB API, so I have had to update it before we publish. The SDK update - while frustrating - was successful and the app still works without any further changes.
There is also a Rails application which uses the same FB App for Omniauth registration/login. The Rails app uses the omniauth-facebook gem, which has been updated. There were no further updates needed for the Rails app either.
The client, however, is requesting "proof" that the app now uses >=v2.0 of the FB API and I am not sure what to give them. FB is clearly capable of knowing when a FB App is receiving outdated API calls, but can it show me whether it's receiving >=v2.0 API calls? So far the only thing I have been able to find is an Insights graph of daily API call counts but there is no information about the calls other than their quantity.
You can look at this dashboard to see if your app is showing in the "Top Affected Apps" table. If so, it will tell you what percent of the calls is v2.x.
Also if you can debug the app, put a breakpoint here: https://github.com/facebook/facebook-android-sdk/blob/master/facebook/src/com/facebook/Request.java#L233
Or call the getVersion() method on your request object to see what version it's hitting.
I think I have the same problem as in this post.
I am using Unity4.3.0f4 and Facebook SDK 5.0.4 beta.
I use the correct key hash (not the debug one) which I obtained by FB.Android.KeyHash. On my own device, as well as on BlueStacks emulator, I manage to log in and FB.Feed normally. However, other users that have tested the app cannot login. FB.Login("publish_actions", callback) is called, the permission dialog is shown, the user taps OK and then returns to game. Result.text is then
{"is_logged_in":false, "user_id":"", "access_token":"", "access_token_expires_at":"01/01/0001 00:00:00"}
Any idea?
ps. On my phone i have an earlier version of the Facebook app, not the last one.
ps2. You can download my app and take part in the beta testing to see the problem yourself.
Ok, after all the problem was that I was trying to log in while immediately requesting the publish_actions permission, which by the way is NOT needed for FB.Feed().
FB.Login ("publish_actions", AuthCallback); // WRONG!!!!!!
Finally I used
FB.Login ("", AuthCallback); // Ok
and it works properly at last.
Make sure your test users can see the app.
My guess in your app is sandboxed and your test users are not listed on Developer Dashboard.
Either un-sandbox it, or add them as Testers(its in Roles tab)
I use a Facebook sample app (SessionLoginSample) to understand how to log into Facebook. My Facebook SDK is latest — version 3.0. When I have the Facebook app installed, I can log in without any problems.
The problem is when I uninstall my Facebook app and re-install the sample (so it doesn't log in automatically). I try to log in but I can see only a white empty dialog. The only option I have is to close it. Even if I wait 10-15 minutes, the dialog doesn't change.
I tried to debug the Facebook SDK but I couldn't find what's causing the error.
I tested this on LG-E610 (4.0.3) and HTC Sensation (4.0.3).
Is this facebook sdk error or I'm doing something wrong?
Edit: I tested this issue again 10 days later in the same coditions and everything seems to work as expected.
The problem might not be on your side! I have encountered a situation where one and the same request to Facebook would be answered as expected or with an "Internal Server Error 500" depending on my IP (IP/User agent to be exact).
You can be quite certain that nothing is wrong with your configuration and application when:
Your app works from another network (i.e. another IP)
When the sample app from Facebook (i.e. HelloFacebookSample) runs into the same problem.
For Android see: http://developers.facebook.com/docs/getting-started/facebook-sdk-for-android/3.0/
For iOS see: http://developers.facebook.com/docs/getting-started/facebook-sdk-for-ios/
My suspicion is that Facebook puts certain IP/user agent combinations in a temporary black list. The problem is that their generic 500 response is not helpful.
For another reported case see my question at Internal Server 500 from Facebook with sepcific IP/user-agent combination
I think this might effect a lot of Facebook/Android developers and yet there does not seem to be that much discussion on the topic...
My question
Has anyone successfully refreshed a token using the extendAccessTokenIfNeeded function? If you did have success, what version was the device (or emulator) running?
Background
I received an email from Facebook saying the offline_access permission will be deprecated from May 1st 2012 and Facebook recommended upgrading to their latest SDK. Fine.
I upgraded to the latest SDK, the official Facebook app is installed on my device and (eventually!) Single Sign On seems to be working OK. I am receiving 60 day tokens which again is OK.
Problems started when I tried to use extendAccessTokenIfNeeded(Context context, ServiceListener serviceListener). I could not get it to refresh my tokens for a longer expiry time. I waited 24 hours between attempts but the token would not refresh. The only way I can get a refreshed token is to log out and login. This also happened when I used the example project "Hackbook".
The most obvious answer is that I am doing something wrong, but, a bug report was submitted to Facebook saying that... "shouldExtendAccessToken will practically almost always return false." This report has been given the priority "wishlist".
Alternatives to the extendAccessTokenAsNeeded()
In the Facebook documentation about offline_access deprecation tokens can be extended using the Graph API. However this has the disadvantage of needing the "App Secret" being included in the URL. An advantage is that the user would not need to have the official Facebook app installed on their device.
Other ideas and concerns
By changing the extendAccessTokenIfNeeded function in Facebook.java to always return true, I think I got it to refresh once. (The reason I say "think" is because it won't repeat the behaviour and I suspect I have to wait another 24 hours before any chance of another success)
I notice that Hackbook requires AndroidHttpClient to be
imported. This is only available for API 8 onwards. Does this mean
that Facebook SSO (in particular token refreshing) is only likely to work on devices with API 8 and later?
The Facebook.apk included in the SDK is quite old. Perhaps this is why the tokens don't refresh on emulators running API 8 and later?
And lastly, all of this only relates to those people that have the
official Facebook app installed! Another method needs to be completed for those people without the official Facebook app (just complaining now!)
Relevant Facebook links
Facebook-Android-SDK at GitHub
Facebook Android Tutorial
Facebook offline_access permission deprecation
Facebook bug report
Related Stack Overflow Questions
Facebook 60 day access token and Deprecated Offline_Access
Facebook access token can not be extended
How would offline_access work after deprecation after May 1st?
Facebook access token can not be extended
Protecting app secret for extendAccessToken usage (Java/Android)
I don't know Android development, but if you're having issues with that function, maybe there's a similar function of CURL within Android that will allow you to call
https://graph.facebook.com/oauth/access_token?
client_id=APP_ID&
client_secret=APP_SECRET&
grant_type=fb_exchange_token&
fb_exchange_token=EXISTING_ACCESS_TOKEN
(google revealed: http://thesoftwarerogue.blogspot.com/2010/05/porting-of-libcurl-to-android-os-using.html on how to CURL from Android)
Try changing the time of REFRESH_TOKEN_BARRIER, so that you do not have to wait 24 hours every time you want to test. I changed mine to about 2 minutes, and I was able to see that the access token was actually being extended when I re-launched the app after 2 minutes.