This is a very late post on the subject of the closure of external sdcard access. The initial release in 4.4 was so very poor. (https://code.google.com/p/android/issues/detail?id=67570) The above thread was closed with their last post on the subject.
So let's talk about OPEN_DOCUMENT_TREE. On the surface it seems to do what an app would like. On the technical side, it does accomplish it with lots of problems. However, it leads to a poor user experience which is probably the worst of the issues.
It is easy to kick off the selection process, simply add:
Intent i = new Intent(Intent.ACTION_OPEN_DOCUMENT_TREE);
startActivityForResult(i, RESPONSE_ID)
You can give it a list of mimetypes in order to limit the possible locations:
i.putExtra(Intent.EXTRA_MIME_TYPES, mimeTypes);
This open a 'picker' app that is system implemented. It really looks crappy, imo. What's worse is that many devices default to not showing the external sdcard. It only shows the internal flash. The user has to go to the overflow menu and 'unhide' the external sdcard. While there are many users that understand technology, many of them don't and would not expect this. At this point, the typical user will simply select some new directory on the internal flash which doesn't accomplish the goal at all. (Most of the time users are trying to move items to external flash to preserve space of internal flash.)
Issue #2 is that you can't provide a hint to the directory that you would like access to. There are some issues with trying to implement it (more on that later) but it would be nice if you could indicate the storage drive to use and possible path. That way the user can just look at what the app suggests and hit ok or find another location.
Let me give an example here of why would you want it. In my case, I want to provide access to external sdcard due to space requirements. So the app is currently using internal flash and the user would like to use the external flash. The Picker app is bad enough that the user many not realize they are simply picking a new internal flash spot.
Issue #3, you must use a ContentProvider in order to do things like inapp sharing. Unfortunately, many apps, including Google apps, have no standard way of providing it. Some require hard paths to files which is not possible with the new sdcard system. (Note, copying the file to a temp location is not an answer). The destination app crashes most of the time if you give a DocumentFile uri. So you end up having to provide a hodge podge of solutions based upon the request. It is getting better as new versions of the OS come out.
I know Google claimed security when this was implemented but they were not thinking of the user when they did. They didn't implement security for both internal and external flash. It was a very poorly thought out system. And really it was made to enhance Google services rather than help developers or the user. It's unfortunate that they took this track. I like Android and that it is mostly open.
So, enough of the rant, what would I like to see:
1) Ability to provide a path to the directory you would like to use.
2) Indicate the flash to use (there could be more than one external flash drive)
3) Support for URIs in all file handling - some tools require a path to a file and simply cannot work with URIs (that are also DocumentFile uris). Image processing, etc., to name a few.
4) Instead of a uri, allow getting the file path so that the hundreds of libraries out there that use file paths will work. The current method is to retrieve an InputStream to the file and pass it to the library. This probably needs some type of method to determine whether the file is local since the URI could be pointing to some cloud item. The URI won't work for many libraries, they just don't have this ability.
5) Easy way to determine the amount of storage currently used in the device.
Monday, December 21, 2015
Tuesday, September 10, 2013
How to build a better Android JNI library using NDK
I've been using Android for a few years now and just recently had to build a fairly substantial library in C++. I've always hated the typical structure of the JNI layer, at least the one I learned originally. The new library that needed integrating was completely devoid of any JNI structure. Given the nature of the project, I didn't want to hard code the paths.
I looked at a variety of jni code generators. There weren't many restrictions, it did have to build on windows, mac, and pc. After looking at them, I decided my project wasn't that big so it seemed overkill to put in a code generator that would need to be maintained.
In the end, I chose a simple method that gets the job done with minimal frustration. The only real requirement is that you must specify the calling paramters and return code. Once you have done a few, you get used to it and the rest are easy. A code generator would eliminate that need. (Checkout the bottom of this page for some possible generators: jni generator info.)
Typically, it looks something like this:
Java code:
public class FooUtil {
try {
System.loadLibrary("awesomeFooLib");
native_init = true;
} catch (UnsatisfiedLinkerError e) {
}
private native int fooMeN(int blah);
public int fooMe(int blah) {
if (native_init) {
return fooMe(blah);
}
return -1;
}
}
The C layer looks like:
JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *vm, void *reserved) {
return JNI_VERSION_1_6;
}
JNIEXPORT jint JNICALL Java_com_mtterra_android_utils_fooMeN(
JNIEnv *env, jobject self, jint blah)
{
// do something interesting
return 0;
}
The problem with the above is all the hardcoded paths and the general fuglyness of the whole thing. You can use javah -jni <classfile> to generate a header file with the long method names. As much as I would like it to read better, JNI coding doesn't lend itself well for that. However, it can be better. Note: if you are using JNI you should make sure to read JNI Tips.
The new method is to register your JNI functions when the library is loaded instead of hard coding the paths. This allows for much better readability and somewhat better portability. The Java class portion stays the same, only the JNI changes. I used C calling convention above, using C++ (below) just requires wrapping the code with extern "C" and calling functions off of the env pointer is simpler.
#ifdef __cplusplus
extern "C" {
#endif
JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *vm, void *reserved) {
JNIEnv *env;
jint ok = vm->GetEnv((void **)& env, JNI_VERSION_1_6);
// Add a function to register all of the jni calls
if (ok == 0) {
installJNIFunctions(env);
}
return JNI_VERSION_1_6;
}
// Add your normal-looking functions
static int JNICALL fooMe(int blah) {
return 42;
}
// Define all the functions here that need to be registered
static JNINativeMethod fooLibraryMethods[] = {
// Calling parameters are pretty easy, the end of this post has more info.
// The first paramter is the name that your java defines as the native call.
// Then the method signature then the local function to be called.
{ (char * const) "fooMeN", "(I)I", (void *)&fooMe) }
};
void installJNIFunctions(JNIEnv *env) {
// This part defines the linkage to your app. It is a hard coded path but it is also
// very easy to change if you move the code to another app or put it in a library at some
// point.
// In your .h file you would add
// #define FOO_LIBRARY "com/mtterra/android/utils"
// substituting your package name obviously.
jclass fooLibCls = env->FindClass(FOO_LIBRARY);
// Make sure the class was found
if (fooLibCls == NULL) {
env->fatalError("Unable to find " FOO_LIBRARY);
return;
}
// get the number of methods available
int noofMethods= sizeof(fooLibraryMethods) / sizeof(fooLibraryMethods[0]);
// finally, register the methods
env->RegisterNatives(fooLibCls, fooLibraryMethods, noof Methods);
//done....reap the rewards of unmangle names
}
#ifdef __cplusplus
} // extern "C"
#endif
The hardest part is writing the method signatures. In the above example, I is standard for int. So (I)I is an int argument to the method with a return type of int. Looking at a more interesting example:
long foo(String s, int i, String t); This would translate to a method signature of (Ljava/lang/String;ILjava/lang/String)J
To see the full list of java types that can be used and more examples see this. As far as the ndk build tools, there aren't any needed changes to compile the code.
Using the above method makes the code very readable and keeps from complicating the build environment. Of course, if you have hundreds of jni calls then maybe a wrapper or jni code generator would be a better way to go. In general, I have lots of libraries but there are few interfacing points where jni is involved. JNI calls are rather expensive so cutting down the number of calls is a good thing.
---------------------------------------------------------------------------------------------------
QuickLogger Fitness - super quick fitness tracking
I looked at a variety of jni code generators. There weren't many restrictions, it did have to build on windows, mac, and pc. After looking at them, I decided my project wasn't that big so it seemed overkill to put in a code generator that would need to be maintained.
In the end, I chose a simple method that gets the job done with minimal frustration. The only real requirement is that you must specify the calling paramters and return code. Once you have done a few, you get used to it and the rest are easy. A code generator would eliminate that need. (Checkout the bottom of this page for some possible generators: jni generator info.)
Typically, it looks something like this:
Java code:
public class FooUtil {
try {
System.loadLibrary("awesomeFooLib");
native_init = true;
} catch (UnsatisfiedLinkerError e) {
}
private native int fooMeN(int blah);
public int fooMe(int blah) {
if (native_init) {
return fooMe(blah);
}
return -1;
}
}
The C layer looks like:
JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *vm, void *reserved) {
return JNI_VERSION_1_6;
}
JNIEXPORT jint JNICALL Java_com_mtterra_android_utils_fooMeN(
JNIEnv *env, jobject self, jint blah)
{
// do something interesting
return 0;
}
The problem with the above is all the hardcoded paths and the general fuglyness of the whole thing. You can use javah -jni <classfile> to generate a header file with the long method names. As much as I would like it to read better, JNI coding doesn't lend itself well for that. However, it can be better. Note: if you are using JNI you should make sure to read JNI Tips.
The new method is to register your JNI functions when the library is loaded instead of hard coding the paths. This allows for much better readability and somewhat better portability. The Java class portion stays the same, only the JNI changes. I used C calling convention above, using C++ (below) just requires wrapping the code with extern "C" and calling functions off of the env pointer is simpler.
#ifdef __cplusplus
extern "C" {
#endif
JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *vm, void *reserved) {
JNIEnv *env;
jint ok = vm->GetEnv((void **)& env, JNI_VERSION_1_6);
// Add a function to register all of the jni calls
if (ok == 0) {
installJNIFunctions(env);
}
return JNI_VERSION_1_6;
}
// Add your normal-looking functions
static int JNICALL fooMe(int blah) {
return 42;
}
// Define all the functions here that need to be registered
static JNINativeMethod fooLibraryMethods[] = {
// Calling parameters are pretty easy, the end of this post has more info.
// The first paramter is the name that your java defines as the native call.
// Then the method signature then the local function to be called.
{ (char * const) "fooMeN", "(I)I", (void *)&fooMe) }
};
void installJNIFunctions(JNIEnv *env) {
// This part defines the linkage to your app. It is a hard coded path but it is also
// very easy to change if you move the code to another app or put it in a library at some
// point.
// In your .h file you would add
// #define FOO_LIBRARY "com/mtterra/android/utils"
// substituting your package name obviously.
jclass fooLibCls = env->FindClass(FOO_LIBRARY);
// Make sure the class was found
if (fooLibCls == NULL) {
env->fatalError("Unable to find " FOO_LIBRARY);
return;
}
// get the number of methods available
int noofMethods= sizeof(fooLibraryMethods) / sizeof(fooLibraryMethods[0]);
// finally, register the methods
env->RegisterNatives(fooLibCls, fooLibraryMethods, noof Methods);
//done....reap the rewards of unmangle names
}
#ifdef __cplusplus
} // extern "C"
#endif
The hardest part is writing the method signatures. In the above example, I is standard for int. So (I)I is an int argument to the method with a return type of int. Looking at a more interesting example:
long foo(String s, int i, String t); This would translate to a method signature of (Ljava/lang/String;ILjava/lang/String)J
To see the full list of java types that can be used and more examples see this. As far as the ndk build tools, there aren't any needed changes to compile the code.
Using the above method makes the code very readable and keeps from complicating the build environment. Of course, if you have hundreds of jni calls then maybe a wrapper or jni code generator would be a better way to go. In general, I have lots of libraries but there are few interfacing points where jni is involved. JNI calls are rather expensive so cutting down the number of calls is a good thing.
---------------------------------------------------------------------------------------------------
QuickLogger Fitness - super quick fitness tracking
Tuesday, March 27, 2012
Google IO registration day, now!
Ready....set....wait..... more spinner.....more spinner.. sigh
Yeah! Finally got in on my mobile device. See ya all there!
QuickLogger Fitness - super quick fitness tracking
Yeah! Finally got in on my mobile device. See ya all there!
QuickLogger Fitness - super quick fitness tracking
Friday, November 18, 2011
Building Android ICS (ice cream sandwich) with Suse 12.1
The main information for setup and install is best found here: http://source.android.com/source/initializing.html.
That said, there are always build issues since everyone has a slightly different environment. I am currently running Suse 11.4 that has been upgraded over time from 11.1. This is all run under a VM in a laptop set for 3/4 GB of RAM available to it on a 3yr old core 2 processor. Needless to say, it takes a while to build.
There have been several issues that have come up that others may run into.
First, GCC 4.5.0 that comes in 11.3, didn't work. It came up with an internal compiler error in caller-save.c. I heard there were issues with 4.6 and that the best compiler for it is probably 4.4.3. I decided to upgrade to 4.5.1 which comes in 11.4 Suse distro. This fixed the problem.
3/4GB of RAM is a bit low for doing this build. I bumped it to 2GB and it didn't have any issues. I have approximately 20GB of free disk space which seems to be enough. It takes around 6 or so to do the build. I used 2G cache size for the build.
Also, make needs to be version 3.81. Apparently, 3.82 has an bug in it that causes some issues.
The next big issue is with OpenJDK. There is at least one error:
cts/apps/CtsVerifier/src/com/android/cts/verifier/PassFailButtons.java:191: onCreateDialog(int,android.os.Bundle) in android.app.Activity cannot implement onCreateDialog(int,android.os.Bundle) in com.android.cts.verifier.PassFailButtons.PassFailActivity; attempting to assign weaker access privileges; was public
private static <T extends android.app.Activity & PassFailActivity>
^
1 error
make: *** [out/target/common/obj/APPS/CtsVerifier_intermediates/classes-full-debug.jar] Error 41
Digging a bit showed that OpenJDK was the problem. I went and downloaded the Sun JDK which is what is suggested. Download info is part of the top installation link. ICS is built with Java 1.6. Previously, 1.5 was the required java compiler. So setting the location of the JDK is important depending on which type of build you want.
Some additional packages are required. I also did this with a Suse 12.1 64 bit clean install which require even more packages with 4.6.2 as the compiler vs 4.5.1. The full list is outline below.
bison - used by 'lunch' command
glibc-devel libraries (will see missing gnu-stupbs-32.h)
flex
mesa libraries
zlib devel (32 bit)
ncurses devel (32 bit)
gperf
perl-Switch module
libX11-devel 32 bit
I had the gcc-4.6.2 64 bit version installed. You'll need to install gcc & gcc-c++ 32bit as well.
Make sure to load the envsetup.sh before the next step: (source build/envsetup.sh).
After installing, setup the path correctly. For bash, this is:
'export PATH=$PATH;/usr/java/jdk1.6.0_29/bin'
which isn't good enough, had to set the real flag:
'export ANDROID_JAVA_HOME=/usr/java/jdk1.6.0_29'.
In order to get an older revision (the current is 1.7 which won't work), you must signup for an oracle account.
Before you do a make, open development/tools/emulator/opngl/host/renderer/Android.mk. Double check that it has LOCAL_LDLIBS += -lX11 added. This fixes a build error that results in 'undefined reference to XInitThreads'. (Courtesy of Diego Stamigni)
WIth the build 4.0.3 of ICS, there were some build problems using 4.6.2.
- Issue with external/oprofile/libpp/format_output.h, line 94. Change:
mutable count & counts; to just 'count & counts;' With latest ics version this has likely been changed.
- ptrdiff_t does not name a type
Add #include <cstddef> in file external/gtest/include/gtest/internal/gtest-param-util.h
- ParamName set but not used
Comment out the line in frameworks/compile/slang/slang_rs_export_foreach.cpp or you can modified the make with -Werror.
Now do a make -j4 and you should be all set.
NOTE: Using Suse 11.4 with gcc 4.5.1, I could build full-magura but there were a number of problems with full-eng. With Suse 12.1 and gcc 4.6.2, full-eng built without problems.
To run the full-eng emulator, export ANDRIOD_PRODUCT_OUT=~/<android_root>/out/target/product/generic then run the emulator located in out/host/linux-x86/bin/emulator.
Good luck!
That said, there are always build issues since everyone has a slightly different environment. I am currently running Suse 11.4 that has been upgraded over time from 11.1. This is all run under a VM in a laptop set for 3/4 GB of RAM available to it on a 3yr old core 2 processor. Needless to say, it takes a while to build.
There have been several issues that have come up that others may run into.
First, GCC 4.5.0 that comes in 11.3, didn't work. It came up with an internal compiler error in caller-save.c. I heard there were issues with 4.6 and that the best compiler for it is probably 4.4.3. I decided to upgrade to 4.5.1 which comes in 11.4 Suse distro. This fixed the problem.
3/4GB of RAM is a bit low for doing this build. I bumped it to 2GB and it didn't have any issues. I have approximately 20GB of free disk space which seems to be enough. It takes around 6 or so to do the build. I used 2G cache size for the build.
Also, make needs to be version 3.81. Apparently, 3.82 has an bug in it that causes some issues.
The next big issue is with OpenJDK. There is at least one error:
cts/apps/CtsVerifier/src/com/android/cts/verifier/PassFailButtons.java:191: onCreateDialog(int,android.os.Bundle) in android.app.Activity cannot implement onCreateDialog(int,android.os.Bundle) in com.android.cts.verifier.PassFailButtons.PassFailActivity; attempting to assign weaker access privileges; was public
private static <T extends android.app.Activity & PassFailActivity>
^
1 error
make: *** [out/target/common/obj/APPS/CtsVerifier_intermediates/classes-full-debug.jar] Error 41
Digging a bit showed that OpenJDK was the problem. I went and downloaded the Sun JDK which is what is suggested. Download info is part of the top installation link. ICS is built with Java 1.6. Previously, 1.5 was the required java compiler. So setting the location of the JDK is important depending on which type of build you want.
Some additional packages are required. I also did this with a Suse 12.1 64 bit clean install which require even more packages with 4.6.2 as the compiler vs 4.5.1. The full list is outline below.
bison - used by 'lunch' command
glibc-devel libraries (will see missing gnu-stupbs-32.h)
flex
mesa libraries
zlib devel (32 bit)
ncurses devel (32 bit)
gperf
perl-Switch module
libX11-devel 32 bit
I had the gcc-4.6.2 64 bit version installed. You'll need to install gcc & gcc-c++ 32bit as well.
Make sure to load the envsetup.sh before the next step: (source build/envsetup.sh).
After installing, setup the path correctly. For bash, this is:
'export PATH=$PATH;/usr/java/jdk1.6.0_29/bin'
which isn't good enough, had to set the real flag:
'export ANDROID_JAVA_HOME=/usr/java/jdk1.6.0_29'.
In order to get an older revision (the current is 1.7 which won't work), you must signup for an oracle account.
Before you do a make, open development/tools/emulator/opngl/host/renderer/Android.mk. Double check that it has LOCAL_LDLIBS += -lX11 added. This fixes a build error that results in 'undefined reference to XInitThreads'. (Courtesy of Diego Stamigni)
WIth the build 4.0.3 of ICS, there were some build problems using 4.6.2.
- Issue with external/oprofile/libpp/format_output.h, line 94. Change:
mutable count & counts; to just 'count & counts;' With latest ics version this has likely been changed.
- ptrdiff_t does not name a type
Add #include <cstddef> in file external/gtest/include/gtest/internal/gtest-param-util.h
- ParamName set but not used
Comment out the line in frameworks/compile/slang/slang_rs_export_foreach.cpp or you can modified the make with -Werror.
Now do a make -j4 and you should be all set.
NOTE: Using Suse 11.4 with gcc 4.5.1, I could build full-magura but there were a number of problems with full-eng. With Suse 12.1 and gcc 4.6.2, full-eng built without problems.
To run the full-eng emulator, export ANDRIOD_PRODUCT_OUT=~/<android_root>/out/target/product/generic then run the emulator located in out/host/linux-x86/bin/emulator.
Good luck!
Tuesday, December 14, 2010
Skipping entry in package table 0 because it is not complex
I saw this message for a while before investigating it. A couple of google search led me to nowhere. Basically, there were some questions on it but no answers. Given that there are probably a few ways to get into this, its probably better to figure out how to track it down.
So the message looks like the following:
A great message if there ever was one. Anyway, the first thing to do is look at the generated output. In eclipse, its under <project>/gen/<pkgname>/R.java. The R.java file looks like the following:
So its easy to just search for the offending value to determine what value to look for. In my case, it was a style attribute. Some items require a style with a one or more specific items defined. So in the your res/values/styles.xml file you might have something like:
<style name="Theme.myTheme" parent="android:style/Theme.White">
<item name="android:....">value</item>
</style>
The 'value' is the important bit. some item names refer to more complicated values, such as android:textViewStyle. So you can either define another style with the set of common values or replace it with a specific value such as- <item name="android:textSize">14sp</item>
.
After a reload it should be good to go.
So the message looks like the following:
Skipping entry 0x7f090003 in package table 0 because it is not complex!
A great message if there ever was one. Anyway, the first thing to do is look at the generated output. In eclipse, its under <project>/gen/<pkgname>/R.java. The R.java file looks like the following:
/* AUTO-GENERATED FILE. DO NOT MODIFY.
*
* This class was automatically generated by the
* aapt tool from the resource data it found. It
* should not be modified by hand.
*/
package fi.eye.android;
public final class R {
public static final class anim {
public static final int boxanimation=0x7f040000;
public static final int fade_in=0x7f040001;
public static final int fade_out=0x7f040002;
public static final int home_grid_fade=0x7f040003;
public static final int slide_left=0x7f040004;
public static final int slide_right=0x7f040005;
continues for a long time......
So its easy to just search for the offending value to determine what value to look for. In my case, it was a style attribute. Some items require a style with a one or more specific items defined. So in the your res/values/styles.xml file you might have something like:
<style name="Theme.myTheme" parent="android:style/Theme.White">
<item name="android:....">value</item>
</style>
The 'value' is the important bit. some item names refer to more complicated values, such as android:textViewStyle. So you can either define another style with the set of common values or replace it with a specific value such as
After a reload it should be good to go.
Thursday, November 4, 2010
Android ScrollView workaround fun
There are lots of little things that can be rather...headache worthy. ScrollView is a great little widget that with one simple entry, you get scrolling. However, depending on what you put in it, can lead to some interesting results. For instance, don't stick things like Lists in it. In my case, it was a simple EditText box that caused some issues.
Upon launch, EditText grabbed the focus causing the virtual keyboard to come up. This was due to having no available focuses, it chose my EditText box. Digging into it, the obvious solution that has many posts android:focusable="false" and the android:focusableInTouchMode="false". Of course, that doesn't help if you really want to focus on it.
The end result was to set these to false and upon click, change the modes. All to get around the issue with focus firing on this text box. Something like:
And the good thing is none of it affects using the trackball and DPad. Granted this seems like a minor issue. At least it can be worked around.
Upon launch, EditText grabbed the focus causing the virtual keyboard to come up. This was due to having no available focuses, it chose my EditText box. Digging into it, the obvious solution that has many posts android:focusable="false" and the android:focusableInTouchMode="false". Of course, that doesn't help if you really want to focus on it.
The end result was to set these to false and upon click, change the modes. All to get around the issue with focus firing on this text box. Something like:
public OnTouchListener mNotesTouchListener = new OnTouchListener() {
public boolean onTouch(View arg0, MotionEvent arg1) {
notes.setFocusableInTouchMode(true);
notes.setFocusable(true);
return false;
}
};
And the good thing is none of it affects using the trackball and DPad. Granted this seems like a minor issue. At least it can be worked around.
Sunday, July 4, 2010
ADB reporting unknown target device
A quick note for developers updating to Froyo 2.2. After upgrading my Nexus One to version 2.2 (FRF91), the Android Device Chooser that pops up when you try to debug your application indicates the device is an unknown target rather than version 2.2.
The Android SDK and AVD manager will indicate all has been updated (assuming you did that). The solution is to make sure you upgraded Eclipse with the latest version of the adb/ddms plugin. In Eclipse, go to Help->Check For Updates should take care of the issue.
An easy thing to overlook and my first check on Google didn't pull up anything. So maybe this will help someone else.
UPDATE: One caveat, only one usb port actually works for this. Nothing worked while trying to get the other USB ports working. I'll have to dig up another usb cable to try. There have been reports of some dodgy cables.
Cheers
The Android SDK and AVD manager will indicate all has been updated (assuming you did that). The solution is to make sure you upgraded Eclipse with the latest version of the adb/ddms plugin. In Eclipse, go to Help->Check For Updates should take care of the issue.
An easy thing to overlook and my first check on Google didn't pull up anything. So maybe this will help someone else.
UPDATE: One caveat, only one usb port actually works for this. Nothing worked while trying to get the other USB ports working. I'll have to dig up another usb cable to try. There have been reports of some dodgy cables.
Cheers
Subscribe to:
Posts (Atom)