I been looking at this question, and I thought it would be a good idea of using assert only in debug build.
Is there any thing special that I need to configure in Android Studio in order to allow asserts? I also want to guarantee that they will not be presented in release build.
The adb shell setprop debug.assert 1 from your referred question is to be executed on the device you are testing on, so you could whip up a script or even create a custom gradle task for that (gradle docu).
In general I'd recommend to also have your checks in production and handle them in a proper way. A simple solution would be to throw a RuntimeException. With checked Exception you could even handle the recovery from this errorneous states / misuses of your api.
Furthermore, it would make sense to add proper tests that ensure, that your code/APIs only emit "valid" values that can be handled by the rest of your code.
Related
My Android app is coming to the end. Debugging runs OK for many many times without any error. It runs just fine. It's the time for me to build a release and publish the app. I follow all the steps which can be found via Google easily. In fact the signed APK is installed OK and the app starts OK but if user interacts to navigate between screens of the app, it is crashed for no reason. Not all screen switching causes app crash, just some of them and I can notice that maybe it involves Reflection here. I design my own binding system to bind ViewModel behind with the Fragment and using Reflection is a must, no other way.
I totally believe that it is not any fault in my code because the app runs just fine in debug mode. And at the time of nearly completely losing all hope to publish the app, I found a signed version of the APK file in the debug folder (that signed version is generated only if you start debugging the app to run in some targeted device - even some emulator, building in Debug mode won't generate that file). It's very lucky for me that that signed apk works perfectly. I can deploy that APK to a new device and install normally, the app runs expectedly.
So it must be something wrong with the releasing process. Here is some info about configuration for Release mode (mainly in Android Options tab):
Packaging (Packaging properties): Nothing is checked in here.
Linker: I tried both Sdk assemblies only and Sdk and user assemblies but nothing works.
Advanced properties: I checked all options to support all possible CPU architectures (this should not be a problem because in debug mode, all these options are also checked).
At the beginning of learning Xamarin Android, I tried finding information about publishing Android app and did complete a simple test (to deploy a simple app). It worked OK at that time (maybe because it's too simple), but now when it comes to a complex one (mainly involving my binding system which uses reflection heavily) it can be crashed at some user interactions. I also have a separate library project (containing some custom Views) referenced OK in my main project (not sure if that could be a break, however one custom view is used OK while some others may cause crashing). Because all the crashes happen in a compiled build, I cannot debug anything to see what could be wrong.
No code is provided here because there is too much code, it seems to be crashed at many places and one more important reason is the code should not be the problem (for one reason I explained above - it just runs smoothly in debug mode, I even found a signed APK file in debug folder which can be installed OK and the app then runs just OK like in debug mode).
Since you stated you are using a lot of reflection, the first thing to do is:
In the Android Build Settings:
Disable Proguard if it selected
Change the Linker Options to Don't Link
Rebuild a release build
Update: Since this worked and the app no longer crashes.
The linker will sometimes remove code that you want to preserve.
For example:
You will need to determine what classes and/or method are being remove because that have no direct references and are only called via reflection and preserve those to prevent the linker from removing them.
If they are in your code, you can use the [Preserve] attribute.
If they are 3rd party libs or the Xamarin.Android framework, you can create a "hardcoded" fake reference to those classes/members so the linker sees that you need them.
You might have code that you call dynamically via System.Reflection.MemberInfo.Invoke.
If you instantiate types dynamically, you may want to preserve the default constructor of your types.
If you use XML serialization, you may want to preserve the properties of your types.
Ref: https://developer.xamarin.com/guides/android/advanced_topics/linking/
I need to enable logging in my Android's release version. Nothing is currently showing up in LogCat. I'm using Android Studio 1.5.1. Is there something in Gradle that I need to include?
There are a few things you could try.
1) Restart Android Studio and/or your computer. If you're using adb twice or more (e.g. in the terminal as well), things get confused.
2) Make sure you don't have a Logcat filter applied.
3) If you see "Devices | Logcat" it means you have both pieces of content in the same place, and might have accidentally made the Logcat part take up no space – try looking for a resizeable border that you can move to make them sized better.
I'm doing some reverse engineering protection on Android and I want to prevent debugging of the app. I know how to detect when a debugger is attached but is there a way to block it from attaching in first place?
Edit: For clarification and in response to droidpl's answer, I mean ways beyond just setting debuggable=false in the manifest in case the .apk is repacked.
Yes, you can modify your build process to make your app not debuggable. In the build.gradle of your app, in the build type you want to avoid it to be debuggable, set the property debuggable false.
Now if you try to attach the debugger to your process, it won't appear in the running available processes.
I run my Espresso test via Spoon. Often, I get a build successful, with tests not being executed. I assume the cause is there was no alterations to the code of the app in question. I can see why they would do this - Why test an app that just ran the same test and passed? However, my situation is different; testing the app is not my primary concern, but testing what the app controls.
My question: My test will be run on a continuous loop, and the app will not be altered or changed. So is there any way around this?
I assume the cause is there was no alterations to the code of the app
in question.
This is not true. You can run the same test thousands of times with Espresso without changing a line of code.
Make sure you're running it the correct way:
java -jar spoon-runner-1.1.0-jar-with-dependencies.jar \
--apk example-app.apk \
--test-apk example-tests.apk
Also keep in mind that the devices running the test should be visible in adb (run adb devices to check).
With Spoon, a test will not run twice if the first test passed. This is cause it believes if it runs the test again, it will pass and there is no reason for that. Bad design on Square's part if you ask me.
The solution is: gradle clean spoon. clean will regenerate the res files (among others) and make spoon believe that it is essentially a different test. This makes running tests take longer than it should. But it works.
Is there way in which I can run an adb command from inbuilt eclipse UI in Android SDK?
I need to find out if ECLIPSE UI already has this functionality, if not need to go about implementing it.
Till now I have been mainly using adb commands on command line.
If there is no such functionality would implementing a Eclipse plug-in would be the best way to handle this?
I want this as a feature, so I have already ruled out the use of "External tools Configuration" which needs to be configured individually for every project an end user builts.
EDIT:
I don't need another console, may it be inside eclipse or outside. What I want to write is a UI which works according to my specific need but abstracts away the command line details from the end user. Now I can still explore on how to do that, but I was looking for an existing example which does this for its specific need,through its UI and abstracts away the details of command line for its own sake.
Well, you could install a shell plugin, to give you access from within Eclipse, perhaps http://marketplace.eclipse.org/content/easyshell
Or even better, you can execute some Shell commands directly from the console. Looks like this SO question addresses exactly how to do that (and best of all, it is built in already).
Is there an Eclipse plugin to run system shell in the Console?
This would allow you to execute any adb commands, as you would essentially be escaping to the shell anyway.