We've just finished integrating Google AppInvites into our app.
We've noticed the following issues:
Emails are not being sent and SMS's that are sent, are sent with a link that says yields a 404 page. The above issues occur only if I set our "setOtherPlatformsTargetApplication" for Android and iOS, using their clientId's.
Android:
719104993890-lclfrqti11lulpvg18tbbbuv6bah54gh.apps.googleusercontent.com
iOS:
719104993890-fq3npmoqmp7mi9839fhv6ajj8jespkot.apps.googleusercontent.com
Within the app, I'm getting back from Google invite ID's. If I remove the "setOtherPlatformsTargetApplication" then the emails and SMS's go out just fine, with the issue that when opened on an iOS device, it takes them to the Android PlayStore and not the Apple AppStore.
On Phones with a SIM card, there is text being overlaid (white text, light gray background) over our "Custom Image" that says "email only", and I can't seem to find a way to remove the overlaid text.
The app has been uploaded to the PlayStore under the "Beta" release group, still with no success.
Any ideas? #lmoroney
You should only specify the iOS client id using setOtherPlatformTargetApplication() from android, and only the android clientId from iOS. The target app to be installed on the same (the senders) platform has to be the exact same app that is sending the invitation which is already identified by package name(android), or bundle Id(iOS), although you can specify an upgraded version using setAndroidMinimumVersionCode(). Unfortunately calling the api and specifying the android client id from android will cause the invitation to fail as you've seen.
This should also resolve the second issue, as long as you specify the iOS app then it will redirect all iOS receivers to the AppStore, and of course android users to the Play Store. As a side note, if the project that includes your android app clientId only has a single iOS app, then the matching iOS app is unambiguous so you can omit specifying the iOS clientId. In your case, your project must have more than one iOS client specified so you are required to disambiguate by setting the target application in the api.
I hope that helps.
Related
So, we have an app that has a website (production), an app (production) and a new app (beta).
The problem is that all applications but the recent one are production.
Briefly, the Facebook alert said (regarding the package name that is in beta):
The corresponding URL(s) should return a successful HTTP status code. You can verify this using the Sharing Debugger. - Compliant response codes: 200-299 - Violating response codes: 100-199, 300-399, 400-499, 500-599
We got switched from Live to In Development because of that.
Now, the question is:
What should we do next? What would it happened if we keep our status (dev mode) even with production products? There are not that many options here. We cannot set our app to public until closed beta testing is done.
I hope you all find it useful.
Considering you have the icon, privacy policy, all information requested by Fb and you receive notification above, consider:
If you have plenty other apps (web, android, ios, any) and them all are live. Your Fb app should be live too.
If your brand new app is not yet visible (e.g. beta testing), means basically that all your Fb id should returned to in development (according to Fb. Although, your prod apps will stop working).
So, what you can do is, create a specific app which is in development when the others are live. Or, like in our case, we removed Android on Fb from the website (will turn that on again when beta testing is done) and issue got solved at that moment.
The docs state that both my instant and installed app should implement App Links. Why should the installed app implement App Links as well, since I only want my instant app URLs to be surfaced correctly in Google Search with the instant badge? Also, what are the best practices?
Yes - app links enables seamless link resolution to your app, installed or instant. In order for Google Search to surface results for either your installed or instant app, you must setup app links properly for both. In addition, to avoid degrading the user experience from instant to installed, all URLS supported by the instant app should also be supported by the installed app. Hence, as the docs state, both the instant and installed app should implement app links."
Here are the best practices:
Set autoVerify=true in at least one intent filter in both the instant and installed app manifest.
Host one assetlinks.json per subdomain. The file must be served from /.well-known/assetlinks.json on each https subdomain.
assetlinks.json file must be valid json (correct syntax, no BOM for instance) served with header "Content-Type: application/json" and served with an HTTP 200 status on each domain (no redirects)
assetlinks.json file location must be accessible to bots, e.g. robots.txt needs. This means if you include internal urls in the manifest that are only accessible internally, the validation will fail.
Ensure all path claims in your instant app are also in your published regular app.
All declared intent filters must support both http and https in the scheme.
Do not use wildcards hosts in your intent filters (e.g.) In *.example.local, the * will be dropped and example.local will be indexed.
Only one instant app can be supported for each domain. Multiple Instant Apps cannot be associated with the same domain.
Ensure your assetlinks.json is valid for your most popular search results using the tool described in “Confirm the Digital Asset Links files” on the App Link support page.
Test your app links here.
Instant Apps and App Links
As you noted, Instant Apps rely on App Links to work. However, not all devices support Instant Apps, and if your full app is installed, you will want your users to be sent there instead of the Instant App version. So your full app still needs to support App Links too.
The difference between a regular app and an Instant App is that the device will only load a single Activity in response to the App Link the user clicks, instead of needing to download the full package through the Play Store. It's a more seamless experience for the user, but the underlying technology works the same way.
Passing Context Between Instant and Full App
You also probably need some way to make sure your users are handed off between app versions seamlessly, if they choose to download the full version. Android doesn't offer this by default (surprisingly), so you'll either need to build it yourself or use a service like Branch.io (full disclosure: I'm on the Branch team).
I an app for both iOS and Android that I need to link via App Invites - but they have different package names/bundle IDs that represent the same service - how do I link them with goo.gl / the app-invite system?
The android package name differs from the iOS bundle ID because the Android key was lost by the previous developer, unfortunately.
Thanks!
You can send invites between android and iOS. They are linked using the developer console (console.developers.google.com). Both the android app and the iOS app need to be in the same console project. If there is only one of each, then when sending across platforms it's unambiguous which to choose and you can just send an invite. The app invite service will send the proper short links(goo.gl/...) to install/launch the proper app per platform.
If there are multiple instances of a iOS and/or Android apps in the console project, then the client ID must be sent with the invite using Api call setOtherPlatformsTargetApplication(...) so that app invite service knows which of the console apps should be selected.
For same platform, i.e. android to android, the app selected will match the app that sent the invitation, so same platform is not ambiguous.
I'm running a pay-per-install campaign on iOS an Android. The iOS installs seem to be tracking on the app dashboard, but no Android installs are being reported (there are installs though).
I'm trying to confirm reporting as described here.
You can confirm that the volume of installs is being correctly reported in the Insights section for your app in the App Dashboard under "Mobile App Installs". In addition, in the App Summary Page, after choosing your app, there is a time stamp 'Last Mobile Install Reported" for iOS and Android so that you can confirm that an install is being reported (see image below).
I'm calling AppEventsLogger.activateApp(getActivity(), getString(R.string.fb_app_id)); in my activities as instructed.
I also have the proguard lines to keep the SDK working.
Is there something else I'm missing? Is this a bug on Facebook's end?
It looks like misleading info in the documentation. Tracking was working. Real users are showing up on the dashboard, but my own devices were not.
I'm trying to use INSTALL_REFERRER on Android 2.2, and my broadcast receiver is getting called so I know my AndroidManifest.xml is correct. However, the information being passed to my receiver is not what I'm putting in the URL. To me, it looks like default Android Market info and its ignoring the parameters in the URL generated by Google.
Here's my receiver:
public void onReceive(Context context, Intent intent) {
String referrer = URLDecoder.decode(intent.getStringExtra("referrer"));
Log.d("TEST_RCVR", referrer);
}
Here's the log output:
02-16 05:22:06.095: DEBUG/TEST_RCVR(24599): utm_source=androidmarket&utm_medium=device&utm_campaign=search&utm_term=arbitrary software&rowindex=4&hl=en&correctedQuery=
On my Android device, I opened a browser to the Google Analytics site and had it generate a URL for me. I pasted it into the Android browser so it took me to the right place in the Market, I installed my app just fine, but the output doesnt match whats in the URL.
Here's the URL Google made for me that I pasted into the Android browsers address bar...
https://market.android.com/details?id=com.arbitrarysoftware.test&referrer=utm_source%3Dcampsrc%26utm_medium%3Dmedium%26utm_term%3Dterm%26utm_content%3Dcontent%26utm_campaign%3Dnamed
I'm really interested in getting the utm_source to be ANYTHING other than "androidmarket." I'm clearly not understanding why the Android Market overrode / ignored my settings. In my mind, I referred myself to the Market through the browser so they should be honoring my utm_source.
I've run into this before.
It could be one of 2 things:
1] Make sure you've published the newest APK you've uploaded to the android marketplace (obvious I know, but if you don't hit the save button after you've uploaded to the marketplace, that new APK won't ever show up).
2] Make sure you're downloading and installing the newest version. Sometimes it takes up to 5 hours for me to see the latest version on the marketplace. If you've uploaded version 1.1, for instance, the android marketplace page you hit should have the 1.1 version in it. It appears on the web and on the in-app marketplace at different times for me, so it's a bit of a waiting game.
That should ensure that you see the changes you've made, as they do look correct. Another trick I do is make a slight text change (assuming it's a demo app), to ensure that you can tell you've downloaded and installed the newest version.
-Sig