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?
Related
I am trying to put together a little phone app that will take characters from an ExitText and send them out via Bluetooth.
Getting Bluetooth to work seems to have become an impossible task. I have used Bluetooth before with other SDKs and it was simple. I want to replace a program I wrote years ago using VB5 and Bluetooth. It was simple and I had it working in a few hours. With Android Studio I can't seem to find any simple way of using Bluetooth.
Not that there aren't any examples. In fact there are TOO MANY examples. Most seem to be for obsolete versions of Android Studio or have other problems making them impossible to implement in 3.2.1. When I try, get so many errors I know I will never be able to correct them. Others don't throw errors but nothing happens. I don't know what all the code should do so debugging it is impossible. Over the last week or so I have tried 7 different "examples" (as reported by Android Studio "recent" list) and can't get any of them to run.
I did find an example that says it does something similar to what I want. It contains over 300 lines of code! Does that seem realistic?
I guess what I am asking is, can somebody point me in the right direction? Somewhere that I can see an explanation of what is needed and how to create it?
Sorry if this sounds like a rant but in many ways it is.
Things I have tried and that came close to working but don't:
BluetoothChat.
BluetoothhTutorial
SimpleBluetooth
and How to send/receive messages via bluetooth android studio
Thanks
Pete
I'm getting into Vulkan development on Android and am finding that some of the validation layers reported by vkEnumerateInstanceLayerProperties() cause vkCreateInstance() to return VK_ERROR_LAYER_NOT_PRESENT.
I'm working from Google's validation layer example, as well as the validation chapter from Vulkan-Tutorial.com. Through trial and error, I've found that I'm able to create a VkInstance when requesting some of the SDK's provided layers but not others.
After following the setup steps in Google's guide above, my APK contains seven libVkLayer_foo.so files for each architecture and vkEnumerateInstanceLayerProperties() lists seven layers, as expected. But when I try to create a VkInstance with any of the layers below, vkCreateInstance() returns VK_ERROR_LAYER_NOT_PRESENT:
VK_LAYER_LUNARG_parameter_validation
VK_LAYER_LUNARG_object_tracker
VK_LAYER_GOOGLE_unique_objects
Does anyone know what might cause this? I assumed that if vkEnumerateInstanceLayerProperties() knows about a layer, vkCreateInstance() should too. Although, I do see a crash occurring in libvulkan.so immediately after vkCreateInstance() returns. I'm not sure if that is the cause of the VK_ERROR_LAYER_NOT_PRESENT or a result.
If it makes any difference, this is running on an nVidia Shield TV.
Update Oddly enough, the layers that cause a crash seem to be changing. Now I'm able to use VK_LAYER_LUNARG_parameter_validation, even though requesting that layer used to cause a crash.
And just to clarify, I only experience crashes when I use certain validation layers provided in the LunarG SDK on Android. I am able to create a VkInstance with the other validation layers and my callback function does get called.
The problem ended up being a more general C/C++ "undefined behavior" issue, which might also explain why the "trouble" layer changed at one point. Consider a block of code like this, where extensions is a std::vector:
VkInstanceCreateInfo createInfo = {};
...
createInfo.enabledExtensionCount = (uint32_t) extensions.size();
createInfo.ppEnabledExtensionNames = extensions.data();
In general, this works fine. But the code to create the VkInstanceCreateInfo is in a helper method and extensions goes out of scope (i.e., is destroyed) before createInfo is used. So vkCreateInstance ends up with a pointer to memory that's been deallocated.
From the web, I have seen two answers. One is setting -Djcifs.util.loglevel=3 and another is calling jcifs.Config.setProperty("jcifs.util.loglevel", "3").
I do not know how to do the former one in Android Studio, so I did the latter one. But I see no addditional logs (or any difference), so I am not sure whether it worked or not.
Is it possible to use the former method in Android?
How can I know the log level is correctly set? Any way to confirm that additional log is coming from JCIFS?
Android SDK 25 (7.1.1 Nougat) and JCIFS 1.3.17.
I looked into its source code. It was checking LogStream.level. So, I did the following, and it started printing debug messages.
LogStream.setLevel(10);
Why didn't the methods that the web sites showed work?
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.)
I've got an android project that I started from an old standard Java project, so because of the vast difference in target platform, I have a lot of dead code to cleanup.
I've seen UCDetector recommended for finding unused public methods in java projects in Eclipse. I installed it as directed, and it just doesn't show up on the menu, and I have no idea how to get it to work.
Has anyone got this combo to work, or have another recommendation? Or know how to get it to show up?
(I've tried Find Bugs which found some good stuff, but it doesn't find unused public code.)
Big warning!
It might partially work, but beware, cause it doesn't seem to know about XML-defined callback functions.
If you have installed a callback function on a widget, say a button in an XML Style Sheet, and it is not called in code, UCdetector will think it has 0 references, and suggest it deleted. This obviously is wrong, and will render your code uncompilable.
There might be other similar issues, related to Android specifics.
Viggo
Yes, UCDetector works for android projects. I just installed it and it works.
It's available in context menu of project in Package Explorer.