This is the bug/patch tracker for Rockbox. Click here for more information.
Quick links: Bugs · Patches · Rockbox frontpage
FS#11914 - Android related patches
Attached to Project:
Rockbox
Opened by Maurus Cuelenaere (mcuelenaere) - Monday, 31 January 2011, 00:32 GMT+2
Last edited by Maurus Cuelenaere (mcuelenaere) - Saturday, 07 May 2011, 18:03 GMT+2
Opened by Maurus Cuelenaere (mcuelenaere) - Monday, 31 January 2011, 00:32 GMT+2
Last edited by Maurus Cuelenaere (mcuelenaere) - Saturday, 07 May 2011, 18:03 GMT+2
|
DetailsThese are some Android related cleanups and feature additions. I've considered sending these to the mailing list, but posted them here as devs are more familiar with Flyspray.
Non-cleanup patches are 1, 8, 9 and 10; these are to be reviewed (others are rather minor). I've labeled the patches that are incomplete as WIP: 0008-Android-sync-audio-volume-with-Android-system-volume-WIP has the problem that it can't figure out what the intention of the volume change is, e.g. fade-out doesn't require the global music stream volume to go to 0 0009-Android-graceful-shutdown-WIP requires some more changes to both apps/ and firmware/ code (e.g. power_off() isn't called IIRC, so the wakeup will never be signaled) 0010-Android-signal-handlers-WIP works, but doesn't provide any useful info atm. I've looked at libunwind and GCC's backtrace support, but those require adding a library and thus bloating Rockbox for a minor (dev) feature. This could help tracking down native code bugs when going public though. 
0001-Android-port-generate-initial-config-when-no...
(4.1 KiB)
b/android/res/values-nl/strings.xml | 13 +++++++++++++ b/android/res/values/strings.xml | 3 +++ b/android/src/org/rockbox/RockboxService.java | 22 ++++++++++++++++++++++ 3 files changed, 38 insertions(+)
0002-Android-fix-NullPointerException.patch
(0.9 KiB)
b/android/src/org/rockbox/RockboxActivity.java | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
0003-Android-update-project-to-SDKv9.patch
(1.3 KiB)
b/android/android.make | 6 +++--- b/android/default.properties | 2 +- 2 files changed, 4 insertions(+), 4 deletions(-)
0004-RaaA-move-Android-apps-code-to-separate-dir-...
(30.3 KiB)
b/apps/SOURCES | 6 - b/apps/apps.make | 2 b/apps/hosted/android/keyboard.c | 119 ++++++++++++++++++++++++++++++++++ b/apps/hosted/android/notification.c | 97 ++++++++++++++++++++++++++++ b/apps/hosted/android/notification.h | 27 +++++++ b/apps/hosted/android/yesno.c | 121 +++++++++++++++++++++++++++++++++++ a/apps/hosted/keyboard.c | 119 ---------------------------------- a/apps/hosted/notification.c | 97 ---------------------------- a/apps/hosted/notification.h | 27 ------- a/apps/hosted/yesno.c | 121 ----------------------------------- 10 files changed, 368 insertions(+), 368 deletions(-)
0005-Android-remove-rockbox.apk-when-doing-make-c...
(0.8 KiB)
b/tools/root.make | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
0006-Android-replace-installApk.sh-with-make-inst...
(1.3 KiB)
b/android/android.make | 4 ++-- a/android/installApk.sh | 10 ---------- 2 files changed, 2 insertions(+), 12 deletions(-)
0007-Android-refactor-intent-handling-use-use-con...
(5.7 KiB)
b/android/src/org/rockbox/RockboxService.java | 50 +++++------ b/android/src/org/rockbox/widgets/RockboxWidgetProvider.java | 8 - 2 files changed, 30 insertions(+), 28 deletions(-)
0008-Android-sync-audio-volume-with-Android-syste...
(8.1 KiB)
b/android/src/org/rockbox/RockboxPCM.java | 57 +++++++++++++++++-------- b/apps/misc.c | 12 +++++ b/firmware/export/config.h | 1 b/firmware/export/kernel.h | 1 b/firmware/export/system.h | 4 + b/firmware/target/hosted/android/pcm-android.c | 25 ++++++++++ 6 files changed, 84 insertions(+), 16 deletions(-)
0009-Android-graceful-shutdown-WIP.patch
(2.8 KiB)
b/android/src/org/rockbox/RockboxService.java | 11 ++++++++-- b/firmware/target/hosted/android/system-android.c | 23 +++++++++++++++++++++- 2 files changed, 31 insertions(+), 3 deletions(-)
0010-Android-signal-handlers-WIP.patch
(2 KiB)
b/firmware/target/hosted/android/system-android.c | 26 ++++++++++++++++++++++ 1 file changed, 26 insertions(+) |
This task depends upon
Closed by Maurus Cuelenaere (mcuelenaere)
Saturday, 07 May 2011, 18:03 GMT+2
Reason for closing: Fixed
Additional comments about closing: These patches are either committed to SVN or obsoleted by other commits.
Saturday, 07 May 2011, 18:03 GMT+2
Reason for closing: Fixed
Additional comments about closing: These patches are either committed to SVN or obsoleted by other commits.
Also, I don't know if other people have noticed, but there seems to be some issue with the java side makefile target dependencies. I've already had it build only some of the classes when running "make apk" right after "make clean". Running "make apk" a second time will build the remaining classes. Looks like something might be messed up somewhere but I haven't been able to find why.
- I like that the default language is changed, but I don't think we should have two language systems. We can pass localized strings from the native code that is translated with the classic system.
2, 3, 4, 5) go for it
6) If we can make a make-target depend on the install target we could do something like "make install run" (or launch, start, ....) which would be kind of nice. IMO the install target shouldn't start the app on its own.
7) Looks good, but I think we should eventually broadcast key events (if possible) instead doing rockbox-local intents, this way the widget could potentially work with other apps as well (Android handles which app gets the multimedia key events first). Do I understand it right that it starts up the native code if rockbox isn't running? Does it then also execute the action?
8) I'm very happy with the current, separated volume handling. Do we need to change it? People have also told me that it's nice that Rockbox offers a more fine-grained volume control that the global one.
9) I'm fairly sure calling wakeup_wait() from OS context (i.e. outside of a rockbox thread) cannot work correctly. We should probably use a OS primitive to wait for the native code here.
10) What is this good for? Debugging purpose?
2-5) Ack.
6) I'll add a "launch" target.
7a) This patch should possibly be splitted into 2: one "constantizing" the intents and the other refactoring onCreate(). Isn't that a security risk? Or will you only accept such intents from whitelisted apps (e.g. the widget)?
7b) Are you talking about the if(!rbLibLoaded) startService(); hunk? If so, that isn't an addition but a move (look above in the patch).
8) I implemented this because I thought it simplifies user experience, e.g. it could be confusing for new users to have separate volume controls. I can drop this though if wanted.
9) Could be, I'm not familiar with how Rockbox and Java threads react to each other. I used wakeup_* because that was the easiest to implement :)
10) Yes, as the 1st post says: "This could help tracking down native code bugs when going public". A native code backtrace could be useful; but this is more of a PoC right now.
7a) We already listen to global multimedia button broadcasts (for wired headset remotes and cyanogenmod lockscreen controls), this is hardly a security risk. The widget currently doesn't send the broadcast but rockbox-local intents.
8) It reduces flexibility and would be inconvenient for me. As for confused users, I think they'll be fine as long as the volume buttons change volume (they don't necessarily have to use rockbox' volume at all)
9) I suspect the UI thread calls onDestroy(), which is not a rockbox thread. So if it calls into the native code it should be considered as interrupt context.
10) Having backtrace() in debug builds would be awesome, but IIRC it needs register to be used frame pointer. We currently build with -fomit-frame-pointer, but we should be able to change it for debug builds. What if throw an exception and print the backtrace from the java side?
10) I haven't tried throwing exceptions, I'm not sure how useful a Java backtrace would be though (as that would stop at the entry point at the Java side).
I can't imagine that Google didn't add backtrace support for native code (probably only enabled on debug builds), so this could all be a duplicate effort though.
# 1 native code
# 2 RockboxService::startService()
...
I've looked at the ucontext_t parameter, but I don't think Android provides something useful here (NDK doesn't have ucontext_t, haven't looked at bionic though).
Also, see http://stackoverflow.com/questions/1083154/how-can-i-catch-sigsegv-segmentation-fault-and-get-a-stack-trace-under-jni-on-a/1789879#1789879
With calling FatalError() and compiling without -fomit-frame-pointer this results in:
D/dalvikvm( 453): Trying to load lib /data/data/org.rockbox/lib/librockbox.so 0x40512300
D/dalvikvm( 453): Added shared lib /data/data/org.rockbox/lib/librockbox.so 0x40512300
D/dalvikvm( 453): No JNI_OnLoad found in /data/data/org.rockbox/lib/librockbox.so 0x40512300, skipping init
W/dalvikvm( 453): JNI WARNING: JNI method called with exception raised
W/dalvikvm( 453): in Lorg/rockbox/RockboxService;.main ()V (FatalError)
W/dalvikvm( 453): Pending exception is:
I/dalvikvm( 453): Ljava/lang/RuntimeException;: test
I/dalvikvm( 453): at org.rockbox.RockboxService.main(Native Method)
I/dalvikvm( 453): at org.rockbox.RockboxService.access$300(RockboxService.java:55)
I/dalvikvm( 453): at org.rockbox.RockboxService$1.run(RockboxService.java:279)
I/dalvikvm( 453): at java.lang.Thread.run(Thread.java:1019)
I/dalvikvm( 453): "Rockbox thread" prio=5 tid=9 NATIVE
I/dalvikvm( 453): | group="main" sCount=1 dsCount=0 obj=0x4051d670 self=0x1e6b10
I/dalvikvm( 453): | sysTid=461 nice=0 sched=0/0 cgrp=default handle=1991184
I/dalvikvm( 453): | schedstat=( 5180165097 8168308923 633 )
I/dalvikvm( 453): at org.rockbox.RockboxService.main(Native Method)
I/dalvikvm( 453): at org.rockbox.RockboxService.access$300(RockboxService.java:55)
I/dalvikvm( 453): at org.rockbox.RockboxService$1.run(RockboxService.java:279)
I/dalvikvm( 453): at java.lang.Thread.run(Thread.java:1019)
I/dalvikvm( 453):
E/dalvikvm( 453): VM aborting
D/Zygote ( 33): Process 453 terminated by signal (11)
So we probably just need to figure out how to correctly compile our library in order for dalvikvm to print a nice backtrace.