As the answers to this question ( A URL specified in a separate line in Java doesn't issue compile-time errors. Why? ) states you can add code labels on the code without having compilation errors.
Even more, using http:// will work as it will be considered a code label, and a comment.
So I was thinking...
Can I add a number of random code labels (including urls) to the code with proguard to make it even less readable?
Of course I could add them by hand, but that would be a good solution, as it would polute the original code, and what I want it just on release compiled code.
I wanted to do this on Android apps, that's why I'm focusing on proguard (an out of the box solution for Android obfuscation).
You could check AspectJ which allows to create custom modifications of the byte code during build.
However I would not do that. Have you checked if java decompilers show your URLs?
You better optimize your obfuscation such that there is as little as possible in clear text.
No, such labels won't affect the compiled code at all.
A label (be it "http:" or "somelabel:") doesn't show up in the compiled code, not even as debug information. It is only useful in combination with break statements.
A comment (be it "//www.example.com/path" or "//somecomment") doesn't get compiled in either. It is only useful to clarify the source code.
Since java bytecode doesn't represent labels or comments, ProGuard can't add them either. ProGuard also doesn't add unnecessary goto statements
Related
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.
I need to remove all of Android Studios "This can be changed to" warning flags. I know I can reduce all the warning flags with the slider from inspections to Syntax.
I don't know if Syntax covers every non style warning, or if it also includes actual warnings. If it does, can you link me the documentation that says so? I need actual hard proof. I can't find much talking about the syntax warning highlighting.
I can ignore these, no problem but I'm seeing that my team is treating these like real warnings. When you take an existing code base and a team.. we waste a ton of times with hundres of personal style errors. I like to do if(boolean == false), Because it's CLEAR. A lot of these suggestions make the code, bleedin edge 1980s style, save every character efficient, but as readable as.. well.. 1980s code..
For example, we just spent half an hour trying to figure out if we had an error in an if statement, because it "could" have simplified it sorta.
Or my favorites where it tells you to change it, then tell you to change it back..
Also yes I know I can add suppressions, which cause errors in my coworkers Eclipse. . .
See if this helps, Preferences → Editor → Inspections,
Disable the those you don't want, eg. Pointless boolean expression under "Control flow issues"
reference: https://www.jetbrains.com/idea/help/disabling-and-enabling-inspections.html
You can also add this line above the pointless boolean you want to ignore. I use this a lot when using BuildConfig variables as they appear constant but are really not as they are controlled by the gradle build system.
//noinspection ConstantConditions,PointlessBooleanExpression
I am trying to use proguard to obfuscate the code of my Android app.
My problem is that some screen of my app work fine, some others show a blank screen (not entirely blank though, for example my top title bar display correctly, but the rest of the content is blank).
I have started with the basic settings:
proguard.config=${sdk.dir}/tools/proguard/proguard-android.txt:proguard-project.txt
Then, in proguard-project.txt, I have tried to add:
-keep class {my.package.name}.** { *; }
No change
Then
-dontskipnonpubliclibraryclassmembers
No change
Then
-dontobfuscate
which obviously solved the problem but then there is no point since I want to obfuscate my code.
Any idea?
Look at the output ProGuard creates; it will tell you what classes got renamed and what classes got deleted (because they appear to be unused). You will need to modify your config to nether rename nor delete these classes of course. Typically, you can find an interaction between your AndroidManifest.xml and the pieces that are missing after obfuscation (and your logcat might even tell you what is missing). Less likely is that use of reflection led ProGuard to not realize the importance of keeping these things in tact.
If you decide you need full obfuscation for the things that are being altered yet are necessary, you'll need to create thin object proxys that are safe from obfuscation and know how to get to the real classes.
It is very very hard to use the crash reports without knowing the line numbers. Also you cannot debug the code without line numbers as well.
Is there a specific reason to disable the line numbers when using ProGuard?
Thank you.
By default, ProGuard strives for the leanest possible application. It removes all elements from your code that are not strictly necessary for running it. You can preserve line numbers if you expect you'll need them, at the price of a very small increase in application size.
I understand there is the LogCat view to check the messages logged but I can't make sense of it.
When debugging (I use Java primarily) I've been accustomed to stepping over each line of code and finding out the exact point where the program crashes and then doing something about it.
How can I do this with Android development? Is there a way to precisely locate the line which is causing the application to crash?
I can't understand what to make of/how to read the LogCat messages and when I try to step over (using the F9 key or the 'Debug' option in Eclipse) it keeps opening new tabs for inbuilt classfiles (like Instrumentation.class etc) and after pressing F6 a few times over again the app crashes showing 'The application has stopped unexpectedly. Please try again'
Can someone tell me if there's something to be done in a way that I'm not doing here?
Thanks!
Btw if it helps, here's the generated log:
http://pastebin.com/EaqaWUdS
You are using a resource id that doesn't exist at line : 93 of com.site.custom.ModAdapter.getView(CustomListProjectActivity.java
--EDIT : add explanations
You will read a logcat stack trace in the same way as you did in Java : read bottom up and the culprit is the last line of your classes (before the code gets into the android sdk code).
You can do it the other way around, and start from top, stopping at the first class of yours and discarding android classes.
The same reasoning applies when debugging : step into your methods if needed and step over all methods of the SDK unless you want to debug them (and usually you don't, if you really suspect a bug inside the SDK, check the source at grepcode to see the inner mechanics of the android sdk class you are interested in).
Sometimes it gets difficult to track bugs on android, especially for widget layout related bugs because you can only see the code that is executed by the android platform, no code of your is executed, only your data are read from an xml file for instance. If something breaks here, it can be harder to debug. In that case, apply the dichotomy method : remove half line, if the bug doesn't show up, then readd your lines, remove half of them, etc...
It is the same like in java. Basically you need the sources to open the java files instead the class files. Google shows you how to add the sources.
Basically you debug android while staying in your own classes. I barely look into the android classes as the most issues are, of course, located in my own classes.
So just debug like you already do but don't step into methods/classes you don't own unless you have the sources added to your sdk. Even if you have, there might be some classes that aren't open source, so you can't step into the sources there. (Basically all Google API classes)