First - I am not trying to actually obfuscate my code, only optimize and shrink.
I have checked android developers site, I have looked through proguard documentation and I've googled for a few hours. But I still can't find a definitive answer - how do I actually test that my application keeps working after being "proguarded"?
There is a way to export it, install manually onto emulator, then run, see if it works, fix something (sometimes in proguard configurations, sometimes in code), re-export, re-install. That's a bit tedious.
Shrinked and optimized application is a totally different thing from the application I've tested. I can't be sure it will work properly with such changes until I actually test it. Not being able to actually test the application I'm going to publish means I'm publishing untested application. Which isn't something I'd want to.
And while I can stay away from the proguard, it does reduce my application's size significantly which isn't something I can ignore.
Edit: I understand now that to test application I just have to run acceptance tests on exported package. But there is still the question - how do I test my proguard configuration?
The same way you tested it before you processed it with ProGuard. You'll find that once you get your configuration right the end result will just need one final test to confirm things before deployment.
But I would obfuscate, which reduces size quite a bit and avoid optimizing which I have had introduce bugs a number of times over the years.
Related
I'm using Unity 2018.4 to make a 2D game. I am facing a strange error with native code (possibly coming from some library) only in a release version and possibly in Android 10.
I don't know how to interpret the abort message.
Abort message
The only library I used that doesn't start with Unity is libsqlite3.so extracted from the SQLite website itself. (Link here)
I also have the errors coming from Google Play by Android Vitals, but it’s just as unreadable.
Does anyone know how I can solve? My game is already in the Play Store and I am receiving some complaints.
SIGSEGV, nice. Welcome to the club of games programmers who have managed to really crash Android hard. I've got a couple of guesses, but can't say for certain. More info would be useful - is this happening to all users of your release, or just some devices or device families?
I've managed to do the same, but my crash was consistent - happened every time, not just release. I had some libGDX native objects open, then tried to change the activity before closing them. My crash looked quite like yours. Check your screen changes to make sure that you cleanly close all your objects before trying to change activities/fragments.
The fact that you mention release makes me think of ProGuard. If you have it turned on it can aggressively optimise out classes that are 'unused'. This means that if you have classes you use via reflection then they won't be compiled into the release bundle. You could try turning it off completely and making a release, to see if that makes things work again. If this is the cause, look into
-keepclasseswithmembers class [your_class_path].** {*;}
in your proguard-rules.pro.
What I was suspecting was correct, the problem was the 64x library libsqlite3.so, I didn't quite understand what might have happened, I replaced the library with one from this source.
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/
Lately, while attempting to build an interesting open source android-web streamer: Android-Eye, I noticed that several people, including myself have been stumped by process of building the application given that it contains c/c++ code that (I think) needs to be compiled by the android ndk before anything can work. The fact that the dev doesn't seem to be active anymore doesn't make this any easier.
I've been trying to get this to work for well over 3 days now and can say with full confidence that I do not posses the knowledge (especially for the ndk) to get this thing built. The long list of things i've tried is too extensive to be covered in this post but here are a few git issues posted by others that have experienced similar issues as me:
https://github.com/Teaonly/android-eye/issues/32
https://github.com/Teaonly/android-eye/issues/27
I understand that it may look as if I am asking to be "spoonfed" the process of building the application but a few pushes in the right direction would be excellent :)
BTW, I have access to windows and mac boxes incase that influences the build process.
Thanks
Background
I wanted to simplify the usage of DB in an Android app.
For this, I've compared some third party libraries that create a DAO layer.
I've come up with a nice library called "GreenDao" (presentation about it here) . The website shows that it's faster than other competitors (like ORMLite) and is optimized for Android.
The problem
For some reason, on some device (usually old devices, with GB) , I get the next console error when trying to install the app:
Installation error: INSTALL_FAILED_DEXOPT
Please check logcat output for more details.
Launch canceled!
I've searched for the reason of this error, but couldn't find out how to solve it. Many complain about this error, but I can't find out why it occurs, and what can be done.
The error is quite common and known, but it's never mentioned as the result of using this library, yet when I remove the usage of this library, everything works fine...
Also note that on newer devices (like nexus 4) it installs and works just fine, and that the sample itself also works fine no matter which device I test it on.
The question
Why does it occur?
Is it possible that the structure of the classes is just too much for old devices to load, since we use other libraries ?
Could it be that I've reached the limit of code that is supported by android apps?
The jar file itself takes just 87KB ...
How can I solve this?
Ok, I've found the problem and the solution:
It has nothing to do with GreenDao.
It's because the app uses too many jars, so maybe Android has a limitation of code.
The solution is to either delete un-needed jar files or delete a lot of code.
Why and when should I use the android Logging? Should it be used only for debugging purposes? It seems to me that if kept in a production application, it would slow it down considerably.
One key part of my question, is WHEN it should be used...in what cases should I need it? Are there any 'best practices' for using this?
This may be a very stupid or amateur question, but I've never understood the need or felt compelled to use it. I may be missing something.
http://developer.android.com/reference/android/util/Log.html
Also - I already know that logging for errors/verbose/info/etc are different, and some are discarded when not debugging. Please don't reiterate the information that's in the class overview without giving me an explanation why. Thanks!
I agree with you, I never really used it either. I much prefer debugging over log reading (and unit-testing over debugging), when trying to figure out what's happening and getting an error.
Some people argue it can be useful to log "additional details" when your application crashes and get an exception, but I usually reply to them that the exception itself should hold that additional details when necessary, and expose them in its getMessage. Thus, the default stack trace that's included in the LogCat is more than enough to see what's going on.
But anyway, it's always nice to have the possibility to log something, even though I haven't found it really useful so far, you never know when it might help :)
Regarding my comment, see Preparing for Release. (Showing logging should be removed before release, hence not being used in production).
Turn off logging and debugging
Make sure you deactivate logging and disable the debugging option before you build your
application for release. You can deactivate logging by removing calls to Log methods
in your source files.
I used logging the other day, I fired off another thread to do some work but I needed to check some data being produced in the thread, without logging or displaying Toast's, how could I get the values? I'm tried debugging/stepping through code in Eclipse before and just run into several problems.
With logging, I can log each value, view the logcat and know exactly what my code is doing.
You usually debug only when you know there is something wrong. (And when you know, you might write additional test cases.)
With logging (at the INFO level, for example), you can add some additional information to trace the data in the app. This allows you to find out that there is something wrong.
Thus, it adds a higher-level overview.
Additionally, it can be easily disabled, does not slow the app down significantly (if done right), and might thus offer another avenue of approach to see if everything works correctly, with few disadvantages and some advantages. (See also Logging vs. Debugging, especially the links in #smonff's answer.)