Develop Reference

How can I get hold of (or bypass) the Android DPC Support Library?

I'm trying to implement an MDM client app for Android, known in the Android For Work world as a Device Policy Controller or DPC. Google's documentation for building a DPC is here.
The documented process begins with downloading the DPC Support Library. Unfortunately, the download link they provide (to the "EMM Community's Technical Integration" section) doesn't work: you're prompted to log in with a Google account, but after doing so I see this:
We’re sorry...
...but it looks like you don’t have access to this place or content. If you think you should have access to this space, try logging out and back in again using your account menu accessible by clicking your avatar in the top right corner of this page. If this issue persists, please notify your Support Representative and we will troubleshoot further.
Others have had the same problem: there's an issue ticket raised here which is only 2 months old, has no answer but for some reason has been marked Assumed Answered and then ignored.
The steps documented here make it very clear that the DPC Support Library is a required part of the process, and don't describe any alternatives to using it.
So, how do I get hold of the DPC Support Library? Can it be obtained anywhere else? Or failing that, how do I find out what it does so I can reproduce those steps manually in my own code?
Some steps I've already tried:
I have successfully registered for the EMM Community and have access to the EMM API. (i.e. I get a valid response now from Enterprises.generateSignupUrl, and no longer the dreaded "The caller is not registered as an MDM".) That in itself was a long and frustratingly opaque process.
I have built and run the googlesamples/android-testdpc app and looked through the source code. Unfortunately this is a client-only demo: it doesn't communicate with an EMM server and doesn't use the DPC Support Library. Specifically, it doesn't obtain an authorisation token in order to provision a work profile on the device, as documented here.
I have played with the public EMM demo system and its DPC app. That seems to be doing things properly, but as it's closed-source I can't look at the code for either client or server.

Well I now have access, so in that sense I have an answer, but I don't know how useful it'll be to others.
A Google representative replied to my forum post here and granted my organisation access to the EMM Community. Once that was enabled, the steps were as follows:
Create a new Google account using my work e-mail address
Sign into the Cloud Connect portal with that account
Click on EMM Community
Scroll down to the Featured Technical Guidance section and look for the DPC Support Library download link

An alternative to build your own Device Policy Controller app is to use the Android Management API and therefore not have to use the DPC Support Library. This API doesn't have all the features you can get by building your own Device Policy Controller app, but is significantly simpler to implement.

Android Pay Auth and Capture

Apple Pay supports a auth and capture by marking a transaction type as pending.
However in case of Android once we have the FullWallet. And in this we dont have a ability to set the transaction type.
So the question is does the auth and capture dependent completely on the payment service provider?
Or is there some types similar to Apple Pay of setting transaction type as Pending required on Android Pay as well?
I saw some service provider like Stripe which mentions that it supported Auth and Capture and in its FAQs for Apple Pay says that that also supports Auth and Capture. However, no such details about Android were listed. If anyone has tried before.

You're correct on the first point - auth and capture depend solely on the payment service provider. This needs to be supported / handled by the payment processor (e.g. Stripe) in some form - you can think of Android Pay as just a thin layer that simplifies and secures the transfer of the user's card information to them (it's a bit more complex in reality, but that's the gig of it).

How to correctly use and track App-invites?

Background
Google allows to perform app-invites and also track how well they improve your app installations:
https://www.youtube.com/watch?v=UfdCNYXMC9M
The problem
I made a simple app invite, and it seems people do use it, using this code:
public static Intent getAppInviteIntent(Context context) {
return new AppInviteInvitation.IntentBuilder(title,appName).setCustomImage(imageUri).setMessage(message).setCallToActionText(download).build();
}
startActivityForResult(getAppInviteIntent(this), GOOGLE_APP_INVITES_REQUEST_CODE);
This works, but in the Analytics webpage, I can't find a way to show the statistics of the app-invite, and that's even though they say it's automatic (here). Sadly, even what I've found seem quite old and they use deprecated functions.
What I've tried
I thought that maybe it's not quite automatic (because the tutorial has some extra code for the receiver part too, here), and that we might need to add some code, as this docs say :
When the user accepts an invitation and installs the app, getInvitation(GoogleApiClient, Activity, boolean) will update the invitation state to installed and return the invitation data in an intent accessed from AppInviteInvitationResult using getInvitationIntent()
Looking at Google's sample (here), I've noticed they created 2 activities. One is the main activity, which does have a call to "getInvitation" , and another is called "DeepLinkActivity" , and handles deep links (which is probably for extra data, like coupons).
I've also found some stackOverflow questions about the tracking (like here), but all I see is that people didn't succeed tracking yet.
The questions
What is the minimal code needed in order to track the invitations and how well they work, as shown on the video? What should be configured in Analytics page itself? I don't use deep linking currently, so I don't want to use it.
It seems that Google moved the app-invites feature to "firebase" gradle repositories. Is it a must-have? What are the advantages? We currently use the previous ones ("com.google.android.gms:play-services-appinvite:..." ). The dashboard of FireBase doesn't seem to include as much UI for analytics as Google Analytics. Not to mention of app-invites.
If the answer to #1 is that I need to use "getInvitationIntent", does it have to be on the main activity of the app ? Does it have to be in an activity at all (maybe broadcastReceiver?) ?
It seems it's possible to also invite to IOS too ( as shown here and here, using "setOtherPlatformsTargetApplication"). Is this correct? How does it work? What happens when an IOS user clicks the link? What should be put into the parameter of "clientId" and where do I get it from ?
Does G+ have app-invites? If so, does it also have analytics?

Great questions. I'll do my best to answer everything. Please ask if you need clarification.
Analytics tracking requires a tracking Id that you'll need to set using setGoogleAnalyticsTrackingId(String trackingId), which I don't see in your example. This tracking Id is then handed to the downstream events that record analytics tracking events for you:
When invitations are send (both email and sms).
When the invited user accepts the invitation by clicking on the invitation link or button.
When the developer calls getInvitation()
When the developer calls convertInvitation()
So, to answer your specific questions, here goes:
Just add your tracking ID to the builder as described above, and all the tracking events will be reported. No need for a deeplink, that's optional on invites.
Yes, appinvites api is copied to firebase while retaining the original. For now they are exactly the same. Future improvements will be in firebase, so migrate when you have time.
getInvitationIntent() is called on the result returned in the callback from getInvitation(), so the callback should be within an activity. Also, since you'll only expect an invitation immediately after launch, you really only need to check in the main activity and any activity that would be launched from intent filters that trigger on the deeplink. Sounds like you don't use deeplinks, so only the main activity. Generally you should call getInvitation() from all activities that may be directly launched from an invitation, this is how you determine if your app is launched from an invitation.
Yes, invites can go cross-platform in both directions, iOS -> android, and android -> iOS. You need to define both apps in the same project in console.developers.google.com, which is necessary to associate them. If there is more than one iOS app in the project, that api call is necessary to disambiguate the iOS app that is paired with the android app. The ClientID parameter is generated in the console when you create the OAuth Client Id using the pulldown menu from credentials section.
There isn't any separate G+ invites.

Answers:
The Firebase Dynamic Links on Android documentation explains how to view the analytics data shown directly in the Firebase console. The critical step is to follow the Firebase setup instructions, most importantly:
// ADD THIS AT THE BOTTOM
apply plugin: 'com.google.gms.google-services'
The Firebase analytics integration has been streamlined from the legacy integration that required a tracking Id. Now with Firebase only setup and a call to getInvitation() are needed. No additional code or tracking ids required. Remember it takes up to 24 hours to see the results in the console. However, you can see the messages being sent immediately which is a great indication that it's working. Just enable verbose logging as described in Analytics Log Events documentation.
The Firebase and android developer documentation for appinvites are identical.
Yes, you must call getInvitation() to get analytics tracking, and do the setup as described above.
The iOS and Android equivalence apps should be in the same project. Just move them to a single project in the Firebase console. You can just remove one from it's existing project and add it to the other to make a combined project. The change should be reflected instantly.

Integrating Mobile Express Checkout on IOS

I was using Paypal to make payments from my application using MPL. Now I want to enable users to make card payments using Paypal. I have found that to implement this feature I have to move to MPECL. When I am using MPL I used to get call backs regarding the payment status whether its success or failure within my app. Now my issue is
If I use MPECL will I get callbacks to my IOS app about the payment
status?
Are there any nice tutorials in integrating MPECL in IOS/Android?
Also is it possible to use MPL and still accept card payments from
user?
Thanks

1) By callbacks are you referring to IPN notifications? If so, then yes, you'll get them the same way, although the txn_type value may be different.
2) According to this documentation, MPL and MPECL have been replaced by PayPal iOS and Android SDK's. I'd recommend using those instead. There are samples included with the SDK's.
3) Yes, users will be able to pay via PayPal or a credit card when going through the payment flow. If you want to process credit cards directly within your app you can use the new REST API for credit cards or you could use PayPal Payments Pro.

Facebook Invite dialog not opening on mobile devices (iPhone/Android)

this is documented in two separated Facebook bugs
http://bugs.developers.facebook.net/show_bug.cgi?id=17261
http://bugs.developers.facebook.net/show_bug.cgi?id=17260
it has been a month, and Facebook has yet to fix it, my clients are very angry so I am looking for a workaround.
can I create an invite UI of my own and do some graph API calls to get invitations to be sent to selected friends ?

No unfortunately you are at the mercy of Facebook for this bug to get fixed, one of the risks of using a 3rd party platform for this. There is no graph api for this as this functionality is only available via their social plugins. The app requests / invitations too has been particularly volatile, having previously been removed and brought back in a different form (probably due to spamming/abuse).