Prevent code accidentally going into production - android

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).

Related

React Native app not building for Android - SyntaxError: \u can only be followed by a Unicode character sequence

My App is running fine on iOS but will not run on Android. I spent ages last week getting it working, and thought it was , and the problem has returned.
Logs show
Full logs here in case there is other stuff relevant. https://pastebin.com/by6uCmPW
SyntaxError: \u can only be followed by a Unicode character sequence
When I reload I then get a white screen, no errors are shown, and I can't get past this, and it does not change whether i connect to the debugger or not.
I've looked at the source and the error is coming from the following line
Which is this from the React Native source https://github.com/facebook/react-native/blob/a974c140db605ecbdf8d3faa7a079b7e2dcebb09/Libraries/ReactNative/YellowBox.js#L263
After refreshing, I get the following error in logcat, although nothing in the emulator.
06-14 13:52:10.467: E/art(2691): No implementation found for
com.facebook.react.bridge.Inspector
com.facebook.react.bridge.Inspector.instance() (tried
Java_com_facebook_react_bridge_Inspector_instance and
Java_com_facebook_react_bridge_Inspector_instance__)
Ok, I had the same issue and this is the solution I came up with that in order to make it work, I've added console.disableYellowBox = true; to index.android.js after the all imports lines.
As per React Native docs
YellowBoxes can be disabled during development by using console.disableYellowBox = true;. Specific warnings can be ignored programmatically by setting an array of prefixes that should be ignored: console.ignoredYellowBox = ['Warning: ...'];.
RedBoxes and YellowBoxes are automatically disabled in release (production) builds.
It's not an ideal workaround and probably still require some tinkering but by doing that I was able to compile the app.
Then in order to go a couple of steps deeper, I removed the recent addings (console.disableYellowBox = true; from index.android.js) and
replaced {stacktraceVisible ? '\u{25BC}' : '\u{25B6}'} Stacktrace from \src\node_modules\react-native\Libraries\ReactNative\YellowBox.js
with one of those next things:
{stacktraceVisible ? '\u25BC' : '\u25B6'} Stacktrace
{stacktraceVisible ? '-' : '-'} Stacktrace
It seems to fix the problem but not sure how elegant this way is and how you would be able to update every time after yarn or npm i.
What oddly worked for me was moving the entire project into another folder

Issue with app in release mode while everything's ok in debug mode

I have a big problem with an app and I don't understand what's going on...
My app was working fine in debug mode so I decided to publish it.
Once it was on the store O downloaded it and tested it again and noticed there was a huge problem : The app was crashing when trying to access the game center. I had an error of this type : "An error occurred in play games" (it's not the exact message, only a translation of the french message that I got).
I had a look at the console on android studio and saw this error message:
06-16 10:30:34.501 4208-4763/? E/GamesServer: Attempting to access a resource for another application. Check your resource IDs.
06-16 10:30:34.551 4208-4763/? E/MultiDataOperation: Attempt to access application XXXX from application YYYY.
Someone adviced me to unpublish everything and to start again. That's what I did but there's still a problem:
screenshot of the error message on the app in beta mode
I really don't understand what's going on and what to do to solve this issue.
Could you please help me ?
Thanks a lot.
You should check your build.gradle file in the /app folder., and more specifically, the release part of your buildTypes section. Some of those options can wreck havoc if not kept in mind. Example: if you have minifyEnabled true there, it means gradle will obfuscate your code during compile time. One of the things that happens during obfuscation is all your class variable names are changed to something that isn't readily readable to humans, to make it harder to reverse- engineer your app. But a side effect is that if you are using, say, a gson library for mapping JSON to your models, it no longer can figure out what to map JSON fields to. That is why there is the #SerialisedName annotation you can add to the variables to ensure the proper mapping. I am not sure what your problem is exactly, but looking in the buildTypes section is a good place to start.

How to use jcabi-aspects Loggable annotation in android?

I'm trying to keep track of the entire app flow so I figured using the Loggable annotation on every single method in my code would do the job.
My issue is that I can't seem to understand how to setup form scratch the Loggable option, including(to my limited understanding of it):
Importing all dependencies with gradle
Configuring the log4j properties , from inside the code or from a file
Using a PackageInfo class to log all methods in my project
A while ago I played around with Gradle and Android SDK in connection with AspectJ in order to help another user. Maybe you want to check this answer.
P.S.: Your question is very general, so my answer is too. This is StackOverflow, please show some code and/or configuration. Give the community a concrete problem to solve and make your own problem reproducible, ideally via an SSCCE.

Custom Lint Rule: how to handle fix button click

I followed this tutorial and it worked perfect for me. Now I want to add fix issue functionality. I am using Eclipse.
In Lint Warnings view we have Fix button, can I handle it?
For example when we have hard coded string (android:text="Test") in TextView when you click CTRL + 1, help pop up opens with possibility to Extract String. What I am trying to do is to add extract hard coded dp values functionality.
Also it would be great if you could point me where I could find source code of already implemented lint issues.
Thank You.
Lint checks can be written standalone:
Writing a Lint check: http://tools.android.com/tips/lint/writing-a-lint-check
Lint checks source: https://android.googlesource.com/platform/tools/base/+/master/lint/libs/lint-checks/src/main/java/com/android/tools/lint/checks
Lint fixes are part of the ADT pluggin: http://tools.android.com/tips/lint
Lint is integrated with ADT 16 and later. The integration offers a few features above the command line version of lint:
Automatic fixes for many warnings
Lint gets run automatically on various editing operations
Ability to suppress types of errors as well as specific instances of an error
Ability to configure issue severities
Jump directly to the problem source from the lint view
Consider making a plugin for your Custom lint check in IntelliJ Idea Community edition, downloaded from https://www.jetbrains.com/idea/download/, and follow the tutorial at http://www.jetbrains.org/intellij/sdk/docs/index.html.
After then you will come to know that to handle light bulb for the fix of your custom Lint warning you have to extend the IntentionAction class particularly.
And then search for deploying the plugin in the tutorial and finally you will come to know to put the jar of the plugin thus created in the Android Studio/Contents/plugins folder.

Development tools infected?

My antivirus program (CA Anti-Virus) just started reporting the existence of "AndroidOS/SMSTroj.D!generic" in a few of the .dex files generated for my Android projects in Eclipse. (I'm not writing malware!)
Has anyone else seen anything similar?
Is my development environment infected somehow, or is this a false positive? How can I verify and, if it's real, disinfect my system?
I haven't found any info about this trojan (the CA site reports no info). Does anyone have pointers to info about this (in particular about disinfecting the development environment)?
Contacting CA does seem like a good idea, but it might also be interesting to create a blank/hello world app and clean/rebuild the dex files a few times and see if anything picks up. Somehow I doubt a virus would try to parse your program and see what it's doing (other than perhaps permissions of the manifest, I guess you could copy over those from your "infected" project) so a build of any dex I would think should give you the same results. I suspect it's a false positive too. If it comes through clean you can slowly add a few classes at a time from your "infected" project and narrow it down that way.
Yes its a TROJAN.
Have a look here.
https://www.virustotal.com/file/dcf44f7262682ec2274829e6a14dfde470ca60dc1fbb2b76ff1053230ae305c2/analysis/1323302988/

Categories

Resources