I've been encountering this issue that I find has no information on the web and would like some help as I've been working on this for the last few days with no leads.
Why does my java app suddenly stop working for APFS? It works if I move the app to a non-APFS USB, but when I move the App to the SSD which is formatted to APFS, it stops working.
When I checked the app logs, it turns out that for some reason, certain libraries are not being properly imported/recognized by the app when it is run from the SSD formatted to APFS. Why would it behave differently in an APFS SSD vs an HFS+ usb/hard drive?
I've already isolated the case and found that only the APFS is the common factor. I've tested it in other devices, those that run High Sierra without an APFS drive, and those that run Sierra with an SSD that has not yet been converted to an APFS drive, and only those devices which utilize APFS filesystem formatting are encountering the issue.
Additional Information:
Java App has been properly signed, it is distributed personally but not via the App Store.
App is bundled using AppBundler not JavaPackager.
App runs on previous versions of OSX, and has been distributed and tested working on hundreds of Mac Devices with OSX varying between 10.8 - 10.12
Libraries that somehow don’t get recognize are the apache libraries, like commons-lang-2.6 (We haven’t upgraded to 3 yet), commons-logging (had to output the logs manually onto desktop to see what was happening). Strangely, app was able to import sqlite library properly.
Thanks for looking, and would appreciate any advice!
I’ve managed to fix the above issue, but I’m unsure as to why.
Solution:
Update commons.lang.2.6 to commons.lang.3.6
Currently, I’m hoping that it will not encounter any other issue aside from that, but I can only guess as to what was happening.
I think APFS cached a copy of commons.lang.3.6 and used that library instead of my own, so there was an issue with class loaders trying to find the 2.6 version. Since only APFS would have a cached copy, it would allow my app to run on a USB.
I don’t actually know the correct etiquette for finding out the answer to your own question, so please feel free to correct my post if there’s anything I need to change.
Related
It seems like a relatively mundane task to make an app that can send data via bluetooth but I've been banging my head on this for the past few days so I'm looking for any ideas. I'm running OS X 10.10 and using a Nexus 5 Android device. Here's what I've tried so far:
I need a server program running on my laptop and I need a client-side android app running on my phone. However, (correct me if I'm wrong) the server program running on my computer needs to be able to access the Android Bluetooth API because I need to use the BluetoothServerSocket (based on the server-side code provided in Google's Android Bluetooth tutorial).
Since it's server-side code, I need to run it on a server so I built a Java Servlet which I ran from inside Eclipse but I didn't know how to access the Android API from inside a dynamic web application.
So I started following this approach where the Bluecove library made that possible: http://luugiathuy.com/2011/02/android-java-bluetooth/
I tried getting Bluecove to work with OS X but there are a whole host of issues involved with that. I found some workarounds and then got an error dealing with the IOBluetoothLocalDeviceReadSupportedFeatures device that Apple removed in its later OS versions (but Bluecove depended on it).
I found a fix here that installed the old IOBluetooth library and changed the DYLD_LIBRARY_PATH to point to it. Unfortunately, this had no effect (I don't know if I changed the library path properly...I followed the instructions from Solution 1 in the answer from this post).
In any event, I feel like I'm overcomplicating this task and am looking for any guidance - in terms of overall approach or a specific thing I missed. The primary issue is accessing the Android Bluetooth API inside the server program intended to run on my laptop.
I eventually ended up using WiFi to send data since there was better software support for that.
But if someone wants to pursue the Bluetooth path, one possibility is to run OS X Lion (which had the IOBluetooth library) as a VM and run the server-side Bluecove code on the VM. This would require a separate Bluetooth USB dongle to be attached because the VM can't access the bluetooth hardware of its host machine - there may be a way but by default it can't access the in-built bluetooth hardware.
Not an ideal solution but I don't know if there is much choice until Bluecove releases a version that is supported on recent OS versions.
I have this assignment to run a "hello world" Android app.
The problem is the Android app emulator is stuck on the Android loading screen.
I have searched this problem. They said that Android development needs a faster computer to execute apps neatly.
Is there a way to run it on a netbook?
For example, editing the RAM settings and/or SD card settings so that it can run faster?
Realistically I think your best bet is to try and find a used android phone. You can get them VERY cheaply on Amazon or at other retailers.
If you really can't you can try to muck around with the emulator, but even when it's at it's best the Emulator is a miserable way to do development. You can barely get it running as it is - imagine what happens if you do figure some hacky way to get it running and you try to do anything substantial. It will be a nightmare.
I would also look into upgrading your computer if you are really going to do dev work. A machine that can't run the emulator is a machine that probably can't do most of what you're going to be needing to do. Have you tried your schools computer lab?
Also - as a commentor has stated this question is likely off topic for stack overflow.
Edit: Per Chris Strattons Comment:
You might try disabling various things in your IDE (I'm assuming you're using eclipse) - for example Syntax checking. I would also recommened ensuring that you don't have a web browser, antivirus or other software running in the background which might eat up your computing power. If you're going to run the emulator I would strongly recommend making it the ONLY thing you run.
You may want to look into building and running the application from the command line to avoid the overhead of running and IDE at all:
Please see:
Building from the command line:
http://developer.android.com/tools/building/building-cmdline.html
Running the emulator from the command line:
How do I launch the Android emulator from the command line?
Additionally - is your netbook running Windows or Linux? Windows boxes tend to have higher overhead than Linux machines, so you might try installing a lightweight Linux distro (mint perhaps) and seeing if that helps.
If the problem is getting the emulator to start or your emulator is just too slow, you should look into HAXM:
http://software.intel.com/en-us/android/articles/intel-hardware-accelerated-execution-manager
Pretty much all of my emulators are running the x86 image with HAXM for acceleration, and my dev machine has 16GB of RAM. Using ARM images for your emulators is just too slow, especially for your netbook.
Yes, if you are serious about Android Dev (or any Dev really) you need to get something better than a netbook, but for now, see if a little hardware acceleration will do in a pinch.
So I downloaded the ADT bundle at the android website. I tried making a simple project, the one with HelloWord program. I already added an AVD and tried to run my application. At first, I got stuck at
"Waiting for HOME ('android :process:acore') to be launched"
but after searching the net, I learned that I must right click my project and click run as Android Application and then it was able to proceed with the next lnes in the console.
But after some lines, it gets stuck at the line in the console saying
"Starting activity.com.example.myfirstapp.MainActivity on device emulator:5554"
it's been an hour since that line and nothing has happened in the AVD. I tried using 2 ADT bundles, one for my 32-bit computer and one for my 64-bit computer. Both get stuck at the same line. How do I solve this? I've been working with this issue the whole day. Just when I thought it would be a simple installation.
Launch your emulator from Android Virtual Device(AVD) Manager and run your application
One thing that can really stick your program is a virtual device that is eating up too many resources. Try lowering the amount of RAM your virtual device has. Also be sure you have the latest JDK/JRE installed.
Just picked this book up:
http://www.amazon.com/Android-Development-From-Eclipse-ebook/dp/B00EEI5NHO/
Decently well written an very easy to follow. Walks through building an app in decent detail.
Actually the AVD works very slow on normal configuration systems, it requires a very high config PC to run smooth, you have to wait for sometime to continue with AVD, it will start don't worry. But I would recommend you to run and test your apps on a real android device using the USB debugging feature.
I'm trying to use Bluecove for an application I'm writing. Version 2.1 of the jar didn't work, so a little Google showed me that it had always had issues with x64, so I turned to the latest 2.1.1 "snapshot", and I still get that the bluecove_x64 dll is missing. Am I doing something wrong, or should I just look for another API?
I encountered this problem after installing a vendor's bluetooth stack and management utilities. My java app which used bluetooth worked fine before this, after the install I got the bluecove_x64.dll not found error. After much searching, I reverted to an earlier system checkpoint (before I tried installing the "newer" bluetooth) and all was back to normal.
On another system, the toshiba bluetooth software had already been installed. I did a system checkpoint (in case the following was to not work), then went into the device manager, and uninstalled every "device" under bluetooth. Be sure to check the "delete driver software" box too, or they will come right back.
After this, the bluetooth device will appear to be gone. Go to the top of the tree, right click, and do "scan for hardware changes". This should install the Microsoft generic bluetooth drives which then work (for me) just fine on Win7_x64. If this doesn't install them, then you may try searching for a download, or another stack.
I've turned on USB debugging. I have the latest HTC Sync and android SDK components. I'm using Eclipse 3.5 on windows XP. I'm running Android 2.2, and am asking for 2.1 as the minimum in the debugger. I work in Eclipse/Java just about every day, and have for several years. I'm even writing an Eclipse plugin at work as I type this.... neither Eclipse nor Java are new to me by quite a stretch.
When I start a debug session for the "Skeleton App" sample project, I can see my Evo, and the activity launches (with any freshly saved changes), should I select it.
BUT: my breakpoints are ignored, and logCat doesn't see my app's output(see comments below).
*W*hat a *T*errible *F*ailure (As the api so artfully puts it)!
(oh look... a formatting bug. Looks like bold text wants white space to function properly 10/15/2010)
I have tried different android connection types (charge only, disk drive, HTC Sync, and USB tethering) to no avail. I've tried Eclipse 3.6 for a bit before yielding to the inevitable and reinstalling 3.5. I monkeyed with the emulator for a while but ran into a different set of issues (I had to reboot the emulator every time I wanted to make a change... Eclipse's auto-build/hot-swap has me spoiled).
Is there something I can add to (or remove from) the AndroidManifest.XML to deal with this? A magical incantation perhaps? Must I pray towards San Jose three times a day on a rug woven from kernel gurus' vast and scruffy beards? Is my Evo not Kosher? Must I be "sky clad" while debugging? Shall I teach my laptop to genuflect?
Have you followed all the points from here ? You need to set a flag in the manifest and also enable debugging on the actual device.
I found the solution to the debugger issue. Google comes through again:
I found an IOException hiding in my DDMS log: Address family not supported by protocol family: bind
Googling for that, plus "android" turned up the answer in the first link. Windows Vista specifies "localhost" as ":::1", but android doesn't really support IPv6 yet. Changing localhost to "127.0.0.1" resolved the issue.
This is defined in c:/windows/system32/drivers/etc/hosts. I needed to run notepad "as admin" in order to save the changes.
I also have an HTC Evo 4G, and have been having the same debugging problems with Eclipse Helios (3.6). I just learned to use this debugger a day or two ago, and it worked fine. I noticed that there was an automatic Android OS update in the last day or two, also. Perhaps this is just a coincidence.
BUT - my beard was indeed scruffy yesterday, as you suggest, and the debugger was working. I've since shaved. Bad idea, apparently.
Butt seriously - I powered down both Evo and computer (HP running Vista), removed battery from both, then started over. Same result, that is, no debugging.