The path string in FileObserver jni will not be automatically released
in the while loop. Then it will cause too many local refs in the ref
table. When received too many file changed notifications/events, the
process will be killed for "Failed adding to JNI local ref table".
Test code:
=============================================================
import android.app.Activity;
import android.os.Bundle;
import android.os.FileObserver;
import android.util.Log;
import java.io.File;
import java.io.IOException;
public class TestApp extends Activity {
public static final String TAG="TestApp";
FileObserver observer;
@Override
public void onCreate(Bundle icicle) {
super.onCreate(icicle);
setContentView(R.layout.main);
observer=new FileObserver("/tmp"){
@Override
public void onEvent(int event, String path) {
if(event == FileObserver.CREATE){
Log.e(TAG, "File created [" + path + "]");
}else if(event == FileObserver.DELETE){
Log.e(TAG, "File deleted [" + path + "]");
}
}
};
observer.startWatching();
File f=new File("/tmp/a.txt");
for (int i=0;i<300;i++) {
try {
f.createNewFile();
} catch (IOException e) {
}
f.delete();
}
}
}
================================================
The last 2 lines of the log:
E/dalvikvm( 705): Failed adding to JNI local ref table (has 512
entries)
E/dalvikvm( 705): VM aborting
When reading a native handle that has passed through the binder,
the fds have to be duped to prevent them from getting closed when the binder
object is destructed.
Signed-off-by: Rebecca Schultz Zavin <rebecca@android.com>
AIDL generates unnecessary "import" statements. These cause warnings
within Eclipse when the default Eclipse warnings settings are used.
This is inconvenient since the generated .java files are not
editable. Some pesky organisations have a zero-warnings policy
too, so there's no option but to fiddle with the Eclipse settings.
This patch ensures that all usages of class names within the
generated code are fully-qualified. In practice, they were nearly
all fully-qualified already. And this patch also removes the
generation of the import statements, since they are redundant
if we're using fully-qualified names everywhere.
This should fix issue 43 in the Google Code Android issues tracker.
http://code.google.com/p/android/issues/detail?id=43
I would appreciate if somebody who knows exactly how 'aidl'
works could confirm that there's no reason 'import' statements
would have been necessary except for the bits I've fixed. (I think
unqualified names were used much more frequently in early versions
of aidl, which might explain why import statements are generated
so eagerly).
There were too many verbs in this sentence. Ideally this patch should
also be applied to some of the other languages. German seems OK but
French not - and that's as far as my linguistic abilities go. I
haven't fixed the French since I'm only 99% sure I wouldn't mess it up!
I chose "read" not "use" because this permission does not allow
writing to the frame buffer; it currently only controls the
screenshotting functionality inside SurfaceFlinger.
Since some of those constants are used in the persistent database,
modifying them for cupcake meant that the new code was getting
confused by the old persistified data after an upgrade to cupcake,
teh most visible symptom being that downloads that had been initiated
from the browser would re-appear in the notifications.
The new names will allow for better consistency and better API
documentation if/when they're made public in the SDK.
This will be followed by a later change that removes the old names
