Was just messing around with JUCE/android and happened to be checking out the code: it looks like MACAddress::findAllAddresses has a TODO.
Some quick Googling shows that it's possible to get the mac address of the device: http://stackoverflow.com/questions/11705906/programmatically-getting-the-mac-of-an-android-device
Likewise for the other TODO in the same file juce_android_network.cpp, Process::openEmailWithAttachments(): http://stackoverflow.com/questions/8701634/send-email-intent
Don't have time to dig into how to hook all of this up and test, but thought I'd just share the findings!
Thanks Joel - that's helpful!
It's so tedious to write all the JNI glue code though.. We'll add it to the backlog!
FWIW, my original FindAllAddresses did (and still does) work with Android. But the socket calls are really whacky because of the underlying flavor of Linux. I don't remember needing any java glue, but I'll double check.
I just spelunked back into the Java and glue for asset_manager access. I remembered it as bad when I put in suspend/resume and hyperlink support in the early Android support days, but yuck! I had a bunch of large binary assets so I put them in the package. Works fine for iOS and Mac (just different paths), and no problem on Linux and Windows where I manually package the extra files with the executable. Massive pain on Android. You can create an assets folder and drop the files in and they will get bundled in the .apk file, but they don't automaticlly get extracted anywhere. You have to create an asset_manager on the Java side and pass it in to the library, then use asset manager functions to access the files.
I should generalize it:
- Introjucer knows to put package files in the assets folder for Android, and creates a .cpp or .h with bundled file info for all platforms
- A BundledFiles class that let's you access the bundled files on all platforms. This would save stuff like the #if JUCE_MAC Contents/Resources, if #JUCE_IOS ./ code I always put in anyway.
I like the JUCE method of sticking binary resources in executables as const data, but now that the mobile platforms are all multi-target bundles, it really cranks up the size of the download object.