Develop Reference

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.

Google Analytics for Android tracking id protection

I am integrating my Android application with Google Analytics and was wondering what kind of security measures should be taken to avoid my analytics data being deliberately polluted by bad people. Sure, GA data is not production-critical, and there are (hopefully) not too many people running around who do such things just for fun, but still - within reason, I'd like to apply whatever preemptive measures there are.
Right now the only thing that comes to mind is that I should avoid the tracking id falling into bad hands.
Google search results I found only talk about:
protecting the tracking id for webpages - not so much talk about how to do the same for Android applications
setting up a GA filter to include traffic data for my own webpage only - again, this is just for webpages...
When submitting hits from my app, there seem to be two ways for the data to reach the GA servers:
If Google Play Services is not installed, putHit runs and fires an HTTPS query with the hit data. If log level is set to debug, I can see this happening, and the data in the ADB logs, along with the tracking id.
If GPS is installed, that will take care of dispatching presumably also over HTTPS.
So this leads me to think that the best I can do on the application front is to make sure log level is above debug (which is a good idea regardless) and to encrypt the tracking id to at least make it difficult to extract from the APK.
On the GA front, I have not found anything similar to the webpages-filtering solution.
Is there anything else I can do?

After you login into: Google Analytics
Under Admin > View > Filter > New Filter > Custom - you could possibly choose to filter by Application Id.
Application Id i believe is the package name you set in your manifest file.
Again this is not fool-proof:
Anyone else can setup the same Application Id too, but it will require more effort.
Google Analytics - shud hv provided a better way to solve this.

Application-Integrated "Send Feedback"

I'm looking for an .jar or library project that will allow users of my application to easily send feedback from inside the application about their experience.
As asked in this question, I am looking for something similar to the crash reporting tool used in Google Plus, that allows the user to get in contact with me, besides leaving bad reviews.
Some not-quite there solutions that came up in answers to other questions:
ACRA : Application Crash Report for Android (functions as a crash reporting tool)
Hockey Kit: Helps distribute betas, nothing related to send feedback to developer.
Does a library like this exist? Is there an easy way to gather user feedback from within the application?

For a full-featured user support service, you can have a look to Capptain: http://www.capptain.com/
But with ACRA you can also trigger a report programmatically. You could call the method handleException(new UserRequestedException()) when the user selects an option in your preferences screen, for example.
You would then filter your ACRA reports spreadsheet for all stacktraces containing UserRequestedException.
UserRequestedException would be a custom Exception that you would implement.
The NOTIFICATION mode can be configured to display a form containing an e-mail field and comments field. The e-mail given by the user the first time is saved in the apps preferences.

A bit late to answer your question, but you might want check out this: http://www.android-feedback.com/ . Its an in app feedback / support system. Its not live yet, but the beta stage is going to start in a few weeks. (and beta testers get bumped to the premium/paid plan once live)
Edit: Disclaimer: its my project

i think you need to use a tool like instabug it provides you a way for collecting bug reports and feedbacks about user experience and also you can talk back to them

As of this date (27th April 2018), HockeyApp can handle this issue. It enables users to send In-app Feedback to developers, which then developers can access through a Dashboard.
Check out: www.hockeyapp.net
The problem I've had with implementing HockeyApp, is that, the feedback form requires the user to add unnecessary details like name, email, etc. I can't seem to find a way to add these detail programmatically.

Best approach to identify if user paid for an app on google play

I seem to have reached dead-end as to how may i create a proper model which plays well under a scenario that i have in mind.
The scenario is as follows; User purchases an application from Google play. At run-time i request user credentials (Google account associated with current device) which i then transfer to a web-service. At that point the back-end service tries to Auth user and identify if they have actually purchased the application in question and only then return any data relative to the request. (keep in mind that any request in general, as we are talking about a content based application, to the web-service at any point of the run-time life-cycle must always pass through the above pipe).
Now the reason for the above scenario being so specific is for the following reason;
-I would like everything to be managed by the end service rather than having any Auth process running natively as it may easily get bypassed. What i mean is that as long as anyone can decompile the application on their device, inspect the code, recompile it to their needs, have full access to any file if the device is rooted or even be allowed to clear any data related to the application by simply pressing the "clear data" option from android's application settings..... i do not see any other viable scenario other than the one i described above.
Now having said all of the above my problem is that it seems that Google does not like this specific scenario with both Google play developer api and Google+ api.
So i would really appreciate your comments, thoughts and any related materials you may have to offer in regards to the scenario i mentioned and ways to tackle down this problem.

I don't know of any such API that you can use. Why not try LVL, which would make sure that it's actually downloaded from the Android market? And if it's a paid app, the user must have definitely paid for it.
As far as decompiling is concerned, try Proguard. It's not 100% perfect solution, but it's pretty hard to break it.
Now, coming to the content. If you don't want anyone else to steal your content, then encrypt and save it. You can have a pretty good encryption mechanism that works with your web services, which would ensure that it's very very difficult to break.

What's wrong with using LVL and ProGuard? These tools were designed specifically to address your concerns with license verification and reverse engineering, respectively.
And, really don't worry too much about the one in a thousand people who might try to get your paid app for free. If your app is any good, then you'll be making plenty of sales anyway.

If I've read your proposal correctly, that sounds like a gross violation of your users' privacy and would definitely be a violation of Google's ToS. Why would your users give you their private credentials? They aren't supposed to be given to anyone, so why should they trust you or your systems with them? You would also be liable if you got hacked and credentials were stolen.

Webservice for Android Market purchases

As Google stores your purchases of Android apps, I was wondering if they are somehow offering a webservice that can be used to check if a certain app has been purchased. To me this seems the most secure way of distinguishing free and paid users from within my app.
It would not only defeat piracy, but would also allow for managing a database of legally registered users, by a one-time check through this service.
What are your solutions to this matter?

Google provides a library for you. See here.
Note that this has been compromised in unprotected apps, so you should use something like ProGuard. The link above contains more information.
Finally, keep in mind that the Android Market is not the only app market for Android out there. Amazon has their own DRM.

At this particular moment there is one way to check.
The Android Market authenticates purchases through Google Checkout, but Google has not implemented the Checkout API to synchronize Market purchases. So calls like that check the status of an order do not work. Maybe Google doesn't want dev's to get a hold of customer emails? Either way, I do not know why it does not exist, it seems to me that if Google simply made this service available we could implement a far more superior security system that would better utilize the methods of obfuscation. As it is at the moment, a hacker can simply look for a specific class like the ILicenceService and hook it.
The only way at the current moment is to download a list of current purchases. You can do this using an authenticated http call. The drawbacks to doing this are pretty large though. First, the list it provides only extends back 31 days (so you've got to make sure you keep everything). Second, you would have to call and parse at least every ten minutes. Actually faster than that, most users want to play their games when they buy them. Third, if your service, or server goes down, that is precious information that is being requested almost instantly by your users.
I don't know how many dev's are currently utilizing this process, I considered it, but am just going to keep complaining to Google for a better method.

You could piggy back off of the LVL. I have just implemented a similar system.
Perform Check via LVL.
On success make a post to your own web server and store whatever details you need, i.e. DeviceID etc.
You could also perform checks to your own server even when the LVL check fails and allow things like trial periods etc.