Develop Reference

Any way to see all the methods that don't work at once? Android Studio

I have to estimate the time it takes to update a specific application made for Android 4.4 to Android 10 and I need to see all the methods that are deprecated or not working. Is there any way to see the methods without going file by file? (I'm using Android Studio with Java)
When I build the application I only get one or two types of error at a time, when I correct them I get another one and so on.
Thanks and best regards.
P.S: How long does it take you to update something like that? I'm a junior and I'm a little lost doing this.

Here, go to Analyze -> Inspect code. After inspecting check maturity there you will have depreciated methods. (Don't forget to change minSdk)
After you will do that it give you method with a warning and you can filter it by having API not support warning

INSTALL_FAILED_DEXOPT when using GreenDao

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.

How do you debug successfully in Android?

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)

How many SSL System.setProperty() options don't work on Android

Its pretty clear that
System.setProperty("javax.net.debug", "SSL");
does not work on Android. One uses it and gets no error. There is no documentation about what works and what doesn't. One only finds out by simply trying it and seeing that nothing happens.
What other standard SSL-related System.setProperty() methods don't work?
Clearly these don't work
System.setProperty("javax.net.ssl.trustStore", trustStoreFileName);
System.setProperty("javax.net.ssl.keyStore", keyStoreFileName);
System.setProperty("javax.net.ssl.keyStorePassword",
keyStorePassword);
System.setProperty("javax.net.ssl.trustStorePassword",
trustStorePassword);
for if they did there would not be all the frustrations with certificates and keystores that Android users have shown in this forum.
This property may not work either, but I am not sure.
System.setProperty("javax.net.ssl.keyStoreType", "BKS");
Does anyone know just what the list of SSL-related property methods that DO work on Android are? Perhaps none?

How to get debugging statements for Android in Eclipse

I've read the lame documentation, and checked other answers. I'd like my Android app to print some debug statements in the logcat window of Eclispe. If I use the isLoggable method on the various types of debug levels on the Log class, I find that WARN and INFO are returning true.
Log.w, and Log.i do not produce any output. Does anyone know which gotchas I've missed?
And just to vent, why should this be hard? I've published apps for iphone and bberry and while appreciate the use of java, the platform is reeking of too many "genuiuses" being involved. I suppose Activities and Intents are very flexible, but why? I just want to put up some screens, take some input and show some results. The bberry pushscreen and popscreen is a lot less pretentious.
Thanks,
Gerry

The problem with debugging with Android in Eclipse is that from Eclipse's point of view, you're debugging the emulator and not your specific app. The emulator isn't crashing, so there aren't any logs to show. What you need to use is LogCat, Android's debugging plug-in. See this answer for details on how to bring that up.

It is not clear to me what the problem is. I use "Log.d(TAG, "special message");" all the time in Eclipse in Android code running in the emulator. Since you say "Log.w" gives no output, I assume you already know about the need to import android.util.Log. Otherwise you would not have got even that far.
The only other thing I can think of is for you to check your Eclipse Preferences under Window>Preferences>Android>DDMS (DDMS is needed for Logcat). Make sure the timeout is reasonable (mine defaulted to 5000mS). Make sure the base local debugger port is open, too.