Develop Reference

Unable to release Android Bundle - location request false positive error

I am developing on React Native and using react-native-geolocation-service library to access foreground location only (App is for office and other location checkin purposes)
I recently faced this issue, last week I was still able to upload and release my aab just fine, but this week I can't anymore although I only changed a few UI based on user's feedback.
So basically permission and logic wise there's no change to my app.
I even compared both app's permission list and both are exactly the same:
But then I'm getting this error
even though I have specifically declared here that I'm not accessing background location
This app targetSdkVersion is 28, if that's important, because I heard starting API 28 there are alot of new restrictions on play console.
Have anyone ever encountered this issue?
If this is a problem with the library I'm using could anyone give me any pointers?
Thanks

Okay got it,
I looked into it and found this
https://developer.android.com/training/location/permissions#foreground
so I just added service tag like so
<service
android:name=".ForegroundLocation"
android:foregroundServiceType="location">
</service>
and updated targetSdkVersion to 29 and it worked!
Although still not sure which causes it to work lol
Can anyone explain this to me? Thanks!

In a Firebase A/B test, how exactly can you target a specific app version on Android?

In "Targeting" section of a Firebase A/B test, you should be able to target by version:
The version of the app (can vary by platform)
Is this supposed to use versionCode or versionName on Android? Simple question, yet I can't find the answer anywhere, and the documentation is useless in this regard.
My initial assumption was that of course it uses the numeric version code (e.g. 789). But I've tried both that and version name (e.g. 5.5.1), and neither seems to work — "0 users exposed"! (Or the delay before the report updates is very long.)
I've also been assuming that Firebase SDK automatically reads the version info, and it's not up to you as developer to programatically set it, but please correct me if I'm wrong!
I'm using Remote Config based A/B tests, should it make any difference.

Right, turns out it uses versionName. (Experiment data was coming in with a long delay so it was hard to tell.)
You can use exact matches, "contains", and regexes:

Black backgrounds are transparent on Lollipop until app is installed a second time

I'm having a bizarre transparency issue with my app on Android Lollipop (and only Android Lollipop).
Steps:
Uninstall any previous versions of my app.
Install the app.
Notice weird transparency on some fragments in my app (full-screen dialog, a fragment we slide in, our pull-to-refresh code).
Build a new binary with no code changes and install on the phone as an update.
Fragments all look fine.
Steps 1-3 I understand -- maybe some material theme is being applied inconsistently, or there's an issue with the custom themes we use in our app.
But I don't understand why re-deploying to the phone fixes the problem.
I'm seeing this on an unmodified Nexus 5 that got the Lollipop update over the air. I see the same issue on the Lollipop emulator.
I've tried changing our targetSdk from 19 to 21 and it did not help. minSdk remains at 15.
Has anyone seen an issue like this and can hopefully point me in a direction to debug?
Edit: Clearing data causes the transparency to return. Force-stopping the app and restarting it fixes the transparency issue. So I think cybersam is on the right track with his answer below -- there's some kind of issue in bootstrapping. But the fragments in question use #android/color:black and #color/my_app_black (= #FF000000) as their background colors, so I don't think the issue is in my app-specific code.

There is not enough information to say for sure what is going on, but I can see one scenario that can cause this. It may be totally unrelated to your situation, but here it is, anyway:
(1) You normally depend on persistent data (e.g., stored in shared preferences, DBs, files, etc.) to determine how to display your background, and have a bug where you: (a) look for the persistent data, (b) see it's not there and use an inappropriate default value (e.g., null) instead, and (c) go on to display strange backgrounds due to the bad default value.
(2) However, you also have special code that detects the missing persistent data and initializes it with appropriate values. But that special code has a bug in that it does not update your in-memory state to match the stored values.
With the above situation, during a fresh install (and as long as the app is not killed by the system and then re-started), you would continue to use the bad data and see the bad backgrounds. During a re-installation (where you did not uninstall the app first), the system would kill your app and then re-install it without deleting its persistent data. Therefore, on a re-installation, bug (1) would not be hit and you would see the expected backgrounds.

Not really an answer, but adding a values-v21 and changing my black color to #010101 works fine. I have no idea what the issue is. Seems like an obscure theme misuse or an obscure platform bug.

Prevent code accidentally going into production

I'm looking for a simple way to make sure my static final boolean DEBUG flag is set to false when exporting my Android project to APK.
I've tried using the "STOPSHIP" comment marker mentioned here, but it doesn't seem to have any effect on apk export, or I'm using it wrong.
Building a lint extension seem an overkill for such purpose, is there a simpler way to do it?
Edit
Using the auto generated BuildConfig.DEBUG flag, combined with some hard to miss on-screen indication that you're running in debug mode (plus a mental note never to upload apk's at 4am after a quick fix) - will probably have you covered.
BUT it is still not the 100% fool proof method I posted this question for.
There are still complaints about BuildConfig.DEBUG randomly not functioning as expected.
So This question is still open - is there a lint trick, or similar trick to do it?

Starting from Android Gradle Plugin 3.0 you can make following configuration in build.gradle file:
android {
lintOptions {
fatal 'StopShip'
}
}
This will break the build as long as there exists a StopShip comment in codebase.
Watch the exact minute of Tor Norbye's "Kotlin Static Analysis with Android Lint" talk, where he talks about the feature.

Have you solved this? I know 2 years have passed, but I just found this while searching what was STOPSHIP after finding it by accident while commenting.
StopShip
--------
Summary: Code contains STOPSHIP marker
Priority: 10 / 10
Severity: Warning
Category: Correctness
NOTE: This issue is disabled by default!
You can enable it by adding --enable StopShip
So I would say you should have executed the command in order to enable it.

I've been using this flag reliably for several years now:
BuildConfig.DEBUG
It doesn't have the issues that occurred long ago, when I posted this question.

You could modify the build.xml, have it read your DEBUG flag from the source and simply change the file name of the APK depending on the value. Make that name explicit enough and you will never distribute or upload the wrong APK (and you can also make it a condition for other following automated processes).

Releasing updates to your android application

I put out an android app last week, and wanted to release an update to it that will include additional phrases to a specific aspect of the app. It isn't a big release that serves as a bug fix (no known bugs actually - fingers crossed ;p) but it will certainly add to the entertainment value of the app and add a lot of flexibility.
Is this poor practice, as new releases should include a lot of content or is this accepted for the most part?
Thanks!

AFAIK, We can release minor updates to the applicatio as well, it is always acceptable and desirable.
I have also released the minor updates to my one of the application, they were for the solving the bug and issues raised in the application.
So you can also do the same !!
But for that You need to Change the versionCode and versionName attributes inside the AndroidManifest.xml file for releasing a udpate version of the same application.
For example:
android:versionCode="2"
android:versionName="1.0.2"

IMHO that's fine - in fact desirable.
Additional content is always welcome.
I use a Spanish Verbs app, and early on it had some important verbs missing, but I was glad when they came in soon after.