Develop Reference

install_referrer intent deprecation

I have received email from google:
We recently announced that we’ll be deprecating the install_referrer intent broadcast mechanism. Because one or more of your apps uses this intent to track referrals, we wanted to ensure you make the switch before March 1, 2020. After this date, new versions of the Play Store app will no longer broadcast the install_referrer intent after app installs.
I am not using install_referrer directly, but while browsing merged manifest i discovered that some firebase service named with package name com.google.firebase.measurement use it.
My firebase dependencies updated to latest version.
Should I care about it?

From Firebase support:
This is a great catch. Thanks for bringing this to our attention.
There's no need [to take] action from your end as of now, I've created an
internal request so we could provide an alternative for the
install_referrer intent broadcast before its deprecation. As of now,
we are yet to find out any details or timelines as to when it will be
implemented. You can check our release notes from time to time for any
updates about Firebase features and its services.
Strange that Google's products are not synchronized.
However if you are not using Firebase and your app contains third party libraries that use install_referrer kindly check directly with them.
To find in which library install_referrer included, open merged manifest and search for install_referrer, check the package name of the service in which the install_referrer included.

com.google.firebase:firebase-core:17.2.1 and com.google.firebase:firebase-analytics:17.2.1 add INSTALL_REFERRER to AndroidManifest. Probably need to wait till Firebase team updates these packages to use the new API.

Various SDKs can register a receiver for the install referrer.
For developers who are unsure about which SDK added a receiver to your manifest it's useful to look at the manifest merge blame file.
Typically, in build/ there's a file intermediates/manifest_merge_blame_file/release/manifest-merger-blame-release-report.txt
In that file you'll need to find receivers that have
<action android:name="com.android.vending.INSTALL_REFERRER" />
in it's intent-filter, and the line before it will indicate what the source of that line is in your manifest.
For instance, the relevant lines for one of my apps looks like this:
44 <receiver
44-->[com.appbrain:appbrain-sdk:15.10] .../jetified-appbrain-sdk-15.10/AndroidManifest.xml:29:9-35:20
45 android:name="com.appbrain.ReferrerReceiver"
45-->[com.appbrain:appbrain-sdk:15.10] .../jetified-appbrain-sdk-15.10/AndroidManifest.xml:30:13-57
46 android:exported="true" >
46-->[com.appbrain:appbrain-sdk:15.10] .../jetified-appbrain-sdk-15.10/AndroidManifest.xml:31:13-36
47 <intent-filter>
47-->[com.appbrain:appbrain-sdk:15.10] .../jetified-appbrain-sdk-15.10/AndroidManifest.xml:32:13-34:29
48 <action android:name="com.android.vending.INSTALL_REFERRER" />
48-->[com.appbrain:appbrain-sdk:15.10] .../jetified-appbrain-sdk-15.10/AndroidManifest.xml:33:17-79
48-->[com.appbrain:appbrain-sdk:15.10] .../jetified-appbrain-sdk-15.10/AndroidManifest.xml:33:25-76
49 </intent-filter>
50 </receiver>
This shows that the AppBrain SDK (of which I'm one of the developers) adds a receiver for the install referrer. The following image from our blogpost explaining what exactly changes (https://medium.com/appbrain/the-google-play-referrer-api-and-the-appbrain-sdk-38cfbaa350dc) is clarifying what Google is changing:

After checking the manifest file on my builded apk, i found the install refeer broadcast used by the firebase-measurement-connector module on Firebase Core Analytics so i exclude them :
implementation ('com.google.firebase:firebase-ads:17.2.0')
{
exclude group: 'com.google.firebase', module: 'firebase-core'
exclude group: 'com.google.firebase', module: 'firebase-analytics'
exclude group: 'com.google.firebase', module: 'firebase-measurement-connector'
}
And then recheck again my manifest mereged file by Analyzing APk and the Install refeer broadcast is disappeared.
On other side, if you use track analytics, Google ask to switch to the Install Referrer API https://developer.android.com/google/play/installreferrer/library.html before March 2020

I checked Firebase support agent for this issue. Firebase libraries are using install_referrer, and I got below response from Firebase support agent:
This is a great catch. Thanks for bringing this to our attention. I'm
currently in discussion with our Analytics experts and will get back
within 48 hours, or as soon as I have more information. For now, no
need for any action from your end, wait for the next update from the
Firebase team.
I believe we need to wait Firebase's next release. And Firebase team updates these packages to use the new API.
If you have used this API in your code by yourself, then you need to change it immediately as you are not depending on firebase or any other third party library provider.

There is one article on Android developer blog about this
https://android-developers.googleblog.com/2019/11/still-using-installbroadcast-switch-to.html
Also in this article they mention old implementation of install_referrer intent broadcast mechanism and provide complete information. So we can find this in our existing code.
https://developers.google.com/analytics/devguides/collection/android/v4/campaigns#google-play-campaigns

INSTALL_REFERRER comes not only with Firebase but also withADMOB. I can confirm that Admob v3.18.3 has this permission but it is no longer coming in Admob v4.2.1. I have not tested other versions but i have heard that some previous versions like 4.2.0 & 4.1.0 also not carrying this permission.
But the question here is whether we need to remove the permission or we need to make sure that if our app is using Play Install Referrer Library then the INSTALL_REFERRER must be included. Because action required is not to remove it but migrate to it.

What is the function or usefulness of the code below in Firebase? [duplicate]

I have an app that utilises Fabric's Crashlytics via Firebase.
The following is the first thing executed in my Applications onCreate
CrashlyticsCore crashlyticsCore = new CrashlyticsCore.Builder()
.disabled(BuildConfig.DEBUG)
.build();
Fabric.with(this, new Crashlytics.Builder().core(crashlyticsCore).build());
Nonetheless, the crashes are submitted in DEBUG == true mode.
I use the following versions
in my build.gradle
classpath "io.fabric.tools:gradle:1.25.1"
in my app/build.gradle
implementation "com.crashlytics.sdk.android:crashlytics:2.9.1"
Unfortunately the crashes still get reported. Any ideas, what I am doing wrong?

Correct answers have been posted by Bob Snyder and niqueco already however it seems kinda tedious to change the meta-data value every time you are building an actual release APK thus here's a solution that uses so called manifestPlaceholder and changes the value automatically to trueor false depending on the buildType.
Add the following to your apps build.gradle
android {
// ...
buildTypes {
debug {
manifestPlaceholders = [enableCrashReporting:"false"]
}
release {
manifestPlaceholders = [enableCrashReporting:"true"]
}
}
}
And this to your AndroidManifest.xml
<manifest ... >
<application ...>
// ...
<meta-data android:name="firebase_crashlytics_collection_enabled" android:value="${enableCrashReporting}" />
</application>
</manifest>
You can verify the current value by clicking on the Merged Manifest tab once you have opened the AndroidManifest.xml. You should see something like this:

The Firebase Crashlytics documentation explains that once reporting is enabled in an app session, it cannot be disabled.
By default, Crashlytics reporting is enabled in a ContentProvider named CrashlyticsInitProvider that executes before your Application instance is created. CrashlyticsInitProvider enables or disables reporting based on the meta-data value firebase_crashlytics_collection_enabled, which by default is true.
If you want reporting disabled, it's critical that the manifest meta-data be present and set to false:
<meta-data
android:name="firebase_crashlytics_collection_enabled"
android:value="false" />
Look in the logcat during app initialization for the message:
CrashlyticsInitProvider: CrashlyticsInitProvider initialization successful
If the message is present, firebase_crashlytics_collection_enabled is true. If the message is not present, you have successfully set the meta-data to disable crash reporting.
If the meta-data is missing or set to true, you cannot disable reporting in your code using a call to Fabric.with(...).
In a comment to another answer, you indicate that you tried disabling reporting using the meta-data and were not successful. Check for a typo and ensure the declaration is correctly placed in the <application> element. In my tests, I am able to disabling reporting using the meta-data and then enable at run time.

I've finally found the issue. Crashlytics is initialized from a content provider, so by the time you try to disable from Application's onCreate() it's too late. Going through the decompiled code I've seen that you can disable that initialization by adding metadata to the <application> element in the manifest.
So, what I do is this... I've added this to app/src/debug/AndroidManifest.xml
<?xml version="1.0" encoding="utf-8"?><!--suppress ALL -->
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="<your app package>">
<application>
<meta-data android:name="firebase_crashlytics_collection_enabled" android:value="false" />
</application>
</manifest>
I've also disabled Crashlytics in the app module gradle build file by adding:
debug {
ext.enableCrashlytics = false
}
To my surprise I didn't need to do the Fabric.with(...) thing. The above was enough.
It's working fine: no reports.

I think it is possible to do it from code as well if you switched to firebase crashlytics and removed fabric crashlytics :
link to firebase doc
So in the onCreate of your application class :
FirebaseCrashlytics.getInstance().setCrashlyticsCollectionEnabled(!BuildConfig.DEBUG);

Got this information from android documentation
Customize your Firebase Crash Reports
Enable opt-in reporting:
By default, Firebase Crashlytics automatically collects crash reports for all your app's users. To give users more control over the data they send, you can enable opt-in reporting instead.
To do that, you have to disable automatic collection and initialize Crashlytics only for opt-in users.
Turn off automatic collection with a meta-data tag in your AndroidManifest.xml file:
<meta-data
android:name="firebase_crashlytics_collection_enabled"
android:value="false" />
Enable collection for selected users by initializing Crashlytics from one of your app's activities:
Fabric.with(this, new Crashlytics());

You need to disable Crashlytics of app’s build.gradle. Disable Crashlytics for Debug Builds
android {
buildTypes {
debug {
// Disable fabric build ID generation for debug builds
ext.enableCrashlytics = false
...

If you would like to completely disable Firebase Crash reporting AND also not have to add the
com.crashlytics.sdk.android:crashlytics:2.9.1
dependency, then follow #reVerse's answer but also add this to your AndroidManifest.xml:
<application ...>
// ...
<meta-data
android:name="firebase_crashlytics_collection_enabled"
android:value="${enableCrashReporting}" />
<meta-data
android:name="firebase_analytics_collection_deactivated"
android:value="true"/>
</application>

How to secure Fabric API Key from APK decompilation?

While decompiling my android app APK file, I have found the fabric ApiKey key in manifest file. How to secure Fabric API Key from APK decompilation?
I have done following code changes for hiding Fabric API key from manifest file. But still it is visible after APK decompilation.
I added my fabric API key
FabricAPIKey=0123456789ABCDEF012345123456789ABCDEF012
in gradle.properties.
In build.gradle(Module)
...........
def FABRIC_API_ID = FabricAPIKey
.....
buildTypes {
debug {
..........
manifestPlaceholders = [//this is used for defining the variable for manifest file
FABRIC_API_KEY:FABRIC_API_ID
]
}
release{ ..........
manifestPlaceholders = [//this is used for defining the variable for manifest file
FABRIC_API_KEY:FABRIC_API_ID
]
}
And in AndroidManifest.xml
<meta-data
android:name="io.fabric.ApiKey"
android:value="${FABRIC_API_KEY}" />

Mike from Fabric here. Seva's point should be well noticed - "a sufficiently motivated hacker can eventually get to it, given a debugger and enough time".
If you want, you can place the API key and Build secret in a fabric.properties file. Copy your api key out of your android manifest, and delete the line that reads: <meta-data android:name="com.crashlytics.ApiKey" android:value="YOUR_API_KEY_HERE"/>
Then make a file called fabric.properties and place this folder in the root of the module that applies crashlytics in its' build.gradle In the fabric.properies file, add:apiKey=YOUR_API_KEY_HERE
Once that's complete, refresh your dependencies to pull in the change: ./gradlew clean --refresh-dependencies

Try to save that in strings.xml and refer that here.
Then manifest will only show resource id in int format.
But if you open the strings.xml file it will be retrieved.

Android App Users Get "App not installed" When Attempting to Update

UPDATE: To those who asked about which error codes the users are receiving: there are no error codes. It just opens a blank, post-installation page that says "The app was not installed" with a big 'X' next to it. It's possible different versions of Android could have different messages. There is no indication for what went wrong during the installation.
UPDATE 2: Some users reported that they receive error code "-504" when they try to install/update from the Play Store, and the "app not installed" message when manually trying to install the .apk. I don't know what correlation this error has with users being unable to install, but the solutions from the only 2 questions on SO on this topic did not fix anything for me. I've included the updated manifests and build files.
UPDATE 3: It appears as users report this issue in versions after IAB has been successfully installed, which further de-legitimatizes the concept that this issue is caused by introducing IAB.
UPDATE 4: It looks like the problem is with old users trying to update to a new version, and not with new users. With that in mind, there is a high likelihood that this issue is result of INSTALL_FAILED_UID_CHANGED. Looking through the version history, the significant change I made in the problematic version that users cannot update from is removing drawables that I no longer intended of using.
Asking users to go through the procedure to fix this isn't plausible. If there is a solution that I can enforce which would fix it for faulty users, wonderful... if not, the least I can do at this point is damage control and ensure this doesn't happen in the future.
NOTE: Below is the original post speculating that the problem is the result of introducing IAB into the app. Since then, it has become more and more unlikely for that to be the cause. Regardless, the post still has relevant information.
------------------------------------------------------------------------------------------
Original Title: Android App Users Get "App not installed" After Introducing IAB
I recently introduced IAB in my app that was published on Google Play. After a while, I've started to get reports from some users that they get an "installation unsuccessful" error when they try to install or update it.
What makes me think it's caused by introducing IAB is that one particular long-time user e-mailed me that when he's attempting to update to the version with IAB, the installer mentions that new permissions were introduced and requires the user's permission. Once granted, it says that the app failed to install.
I've done some Googling and it appears to be a problem from their end, one user even tried to manually install an .apk with said permissions removed without any success. I wan't to make sure that it's not something I've done wrong, but an inevitability that I have to accept with some users.
Note that the vast majority has no problem of installing the app, and I haven't received any reports of this until after IAB was introduced. It wouldn't bother me so much were it a small amount of lost users, but the problem is, those users hurt my app's rating. Users have also mentioned that they can install apps, excluding my own, perfectly well.
I don't rule out the possibility that users may have been getting these errors even before IAB was introduced, and the linkage could be a mistaken one.
Here is my manifest:
<?xml version="1.0" encoding="utf-8"?>
<manifest package = "com.jjsoftware.fullscientificcalculator"
xmlns:android = "http://schemas.android.com/apk/res/android">
<uses-permission android:name = "android.permission.VIBRATE"/>
<uses-permission android:name = "com.android.vending.BILLING"/>
<application
android:allowBackup = "true"
android:fullBackupContent = "true"
android:icon = "#drawable/logo"
android:label = "#string/app_name">
<activity
android:name = ".MainActivity"
android:hardwareAccelerated = "false"
android:label = "#string/app_name"
android:screenOrientation = "portrait"
android:theme="#style/AppTheme">
<intent-filter>
<action android:name = "android.intent.action.MAIN"/>
<category android:name = "android.intent.category.LAUNCHER"/>
</intent-filter>
</activity>
<activity
android:name = ".SettingsActivity"
android:theme = "#style/PreferencesTheme">
<intent-filter>
<action android:name = ".SettingsActivity"/>
<category android:name = "android.intent.category.PREFERENCE"/>
</intent-filter>
</activity>
</application>
Here is the Gradle file:
apply plugin: 'com.android.application'
android {
compileSdkVersion 23
buildToolsVersion "23.0.1"
defaultConfig {
applicationId "com.jjsoftware.fullscientificcalculator"
minSdkVersion 14
targetSdkVersion 23
versionCode 102
versionName "1.679"
}
sourceSets { main { assets.srcDirs = ['src/main/assets', 'src/main/assets/'] } }
}
dependencies {
compile 'com.android.support:appcompat-v7:23.1.1'
compile 'com.google.android.gms:play-services-ads:8.4.0'
compile 'com.android.support:gridlayout-v7:23.2.1'
compile files('libs/exp4j-0.4.5.jar')
compile files('libs/EJML-core-0.28.jar')
compile files('libs/EJML-dense64-0.28.jar')
compile files('libs/Jama-1.0.3.jar')
compile files('libs/EJML-simple-0.28.jar')
}
And, if need be, the top-level build:
// Top-level build file where you can add configuration options common to all sub-projects/modules.
buildscript {
repositories {
jcenter()
}
dependencies {
classpath 'com.android.tools.build:gradle:1.5.0'
// NOTE: Do not place your application dependencies here; they belong
// in the individual module build.gradle files
}
}
allprojects {
repositories {
jcenter()
}
}

There is a typo in the manifest file on line android:largeHeap="true">>. xml line ends with >>. This may be causing the error.

it could be the phones have a lower version of the Google play services than the minimum you defined in the APK.
There is nothing much you can do if that is the case, other than for the users to upgrade their google services (https://play.google.com/store/apps/details?id=com.google.android.gms&hl=en) or you reduce your version.
also you may need to add the following to your manifest. (i think this is used to compare the versions installed in the phones with the versions required by the apk)
<application ...>
<!-- This meta-data tag is required to use Google Play Services. -->
<meta-data
android:name="com.google.android.gms.version"
android:value="#integer/google_play_services_version" />
</application>

I got this error while installing on my Android device a new APK for the app I am developing.
I checked the debug log on the device (using "adb -d logcat > log.txt") and found an entry saying "PackageManager: Downgrade detected: Update version code 2 is older than current 10000". Obviously something went wrong with the versioning somehow.
I uninstalled the package and then was able to install the APK with no problems.

Remember that the latest installment of Android (Marshmallow version) has changed the permissions to give more access to permissions to the user. Hence it is not enough to define the permissions in the manifest anymore.
Through code you need to make sure that the billing permission is enabled by the users when they use the app. The simplest way to go around this is to set the target SDK to v-22. This should temporarily solve your issue.
The real solution however is to handle the new permissions introduced in Marshmallow. Here is how to do it:
#Override
public void onRequestPermissionsResult(int requestCode, String[] permissions, int[] grantResults) {
switch(requestCode) {
case BILLING_REQUEST:
if (canAccessBilling()) {
callBillingPerms();
}
break;
}
}
private void callBillingPerms() {
Toast.makeText(this, "We need your permission to access Billing", Toast.LENGTH_SHORT).show();
}
private boolean canAccessSMS() {
return(hasPermission(Manifest.vending.BILLING));
}
#TargetApi(Build.VERSION_CODES.M)
private boolean hasPermission(String perm) {
return(PackageManager.PERMISSION_GRANTED==this.checkSelfPermission(perm));
}
Hope this helps :)

Perhaps the error is on the user's side.
This article states the following:
Google Play - Error 504
Problem
App could not be downloaded due to an error.
First solution
The usual, please: go to Settings > Apps > All > Google Play Store and Clear cache and Clear data. Also Clear cache and Clear data for Google Services Framework.
Second solution
Try removing your GMail account
This Stack Exchange answer discussed similar ideas.
According to the list of status codes at Wikipedia, a 504 error means the following:
504 Gateway Timeout
The server was acting as a gateway or proxy and did not receive a timely response from the upstream server.
Ask your users if doing the above solves their issue.

Crashlytics found an invalid API key

When I am trying to build project with value of meta-data tag as a string reference, crashlytics fail with following error:
Crashlytics found an invalid API key: #string/crashlytics.
Check the Crashlytics plugin to make sure that the application has been added successfully!
Contact support#crashlytics.com for assistance.
Doesn't work
<meta-data
android:name="com.crashlytics.ApiKey"
android:value="#string/crashlytics"/>
Works
<meta-data
android:name="com.crashlytics.ApiKey"
android:value="1234567890..."/>
I am want to define different keys inside string.xml for different productFlavors of my android project.
Update
After writing to crashlytics support:
Currently we only are able to evaluate the AndroidManifest.xml at build time so we don't look at any strings resources so we only support a hard coded string. I'll definitely share this with the team that you're interested so we can look into supporting this in a future release.

Edit: The solution accepted is working only if you are using an old version of Crashlytics (I was using v1.1.11). If you are using Fabric SDK you will notice
the tasks of the plugin have changed considerably and the script below
will not work. Also the API secret is not needed anymore, therefore
you can just use the <meta> in the manifest to specify the API key along with a manifest placeholder defined in your flavor:
in build.gradle:
flavor1 {
...
manifestPlaceholders = [crashlyticsApiKey: CRASHLYTICS_API_SECRET_HERE]
...
}
in AndroidManifest.xml:
...
<meta-data
android:name="com.crashlytics.ApiKey"
android:value="${crashlyticsApiKey}" />
...
There is another undocumented way to specify the Crashlytics key as noted here, and it is to use the crashlytics.properties (in the root of your project) to specify that value along with the API secret:
apiKey=YOUR_API_KEY
apiSecret=YOUR_API_SECRET
Unfortuntately this will not allow you to simply specify a different crashlytics.properties for each flavor, because it needs to be in the root of your project in order to be picked correctly by the gradle plugin. That means you need to generate that file dynamically.
The idea is to add the key/secret values in your flavor as custom properties, and generate the crashlytics.properties at buildtime, using the values from the current flavor to fill the file.
The build.gradle inside your android module should look like this:
...
productFlavors {
flavor1 {
...
set("crashlyticsApiKey", CRASHLYTICS_API_KEY_HERE)
set("crashlyticsApiSecret", CRASHLYTICS_API_SECRET_HERE)
...
}
...
}
File crashlyticsProperties = new File("${project.projectDir.absolutePath}/crashlytics.properties")
applicationVariants.all { variant ->
variant.productFlavors.each { flavor ->
def variantSuffix = variant.name.capitalize()
def generateResourcesTask = project.tasks.getByName("crashlyticsGenerateResources${variantSuffix}")
def generatePropertiesTask = task("crashlyticsGenerateProperties${variantSuffix}") << {
Properties properties = new Properties()
println "...copying apiSecret for ${variant.name}"
properties.put("apiSecret", flavor.crashlyticsApiSecret)
println "...copying apiKey for ${variant.name}"
properties.put("apiKey", flavor.crashlyticsApiKey)
properties.store(new FileWriter(crashlyticsProperties), "")
}
generateResourcesTask.dependsOn generatePropertiesTask
def cleanResourcesTask = project.tasks.getByName("crashlyticsCleanupResourcesAfterUpload${variantSuffix}")
cleanResourcesTask.doLast {
println "...removing crashlytics.properties"
crashlyticsProperties.delete()
}
}
}
...
Basically the script hooks in the building process and generates/fills the properties file just before the Crashlytics gradle plugin does its magic.

With Fabric's Crashlytics 2.6.6. I'm able to simply select a Build Variant from the menu (usually located on the left in Android Studio) and run the app. It takes a minute or so to propagate through to the Fabric dashboard, but I didn't have any need for a workaround.