Further investigation into com.google.common.io.protocol makes me believe that a custom Protocol Buffers compiler would be needed to compile a .proto file into a .java file that is compatible. Does such a compiler exist? Is it publicly available? Does it let me use a custom package name?
I took a look at com.android.internal.location.protocol files and they look too uniform to be written by hand, though perhaps Google is just really hard on it's employees when it comes to standardizing coding style. ;) If there isn't a compiler then there is little reason left for me to use Protocol Buffers over some of the alternatives since half the point was that I could write one .proto file and compile it for multiple platforms. On Jul 23, 8:08 pm, Micah <[email protected]> wrote: > Is there a way to tell the Protocol Buffers compiler to use my package > name when generating .java classes instead of the default > com.google.protobuf package? Am I going to have to install a C++ > compiler and build my own protocol buffers compiler that uses my > custom package name? > > On Jul 23, 2:52 am, Dianne Hackborn <[email protected]> wrote: > > > > > You should consider using the MIDP protobuf code, which is what is used by > > various Google apps: > > >http://android.git.kernel.org/?p=platform/external/protobuf.git;a=tre... > > > This is much more appropriate for Android. > > > (Note this this is not part of the platform, so you will want to link it > > into your app in a different namespace.) > > > On Thu, Jul 23, 2009 at 2:30 AM, Micah <[email protected]> wrote: > > > > It takes 20 seconds to load the test case class on an ADP1. :( If > > > anyone has any ideas I'm open to trying things out or giving out the > > > test case source code to look at. I don't know what Protocol Buffers > > > does that is causing this, but if I'm not mistaken Protocol Buffers > > > are used internally by the OS so my thought is that someone somewhere > > > knows the answer. > > > > On Jul 22, 2:05 pm, Micah <[email protected]> wrote: > > > > Unfortunately, this doesn't seem to fully resolve my issue. I have > > > > created a very simple repro case that causes the stall to occur (let > > > > me know if anyone wants the source / APK). In the test, it will > > > > eventually finish but it takes ~10 seconds just to make the call: > > > > > Class.forName("com.zoltu.AndroidTest.Messages.Sample") > > > > > On the plus side, the sample code isn't deadlocking, but it looks like > > > > I'll still need to test on a physical device to see if it takes a > > > > noticeable amount of time there like on the VM. > > > > > On Jul 22, 10:49 am, fadden <[email protected]> wrote: > > > > > > On Jul 21, 10:56 pm, fadden <[email protected]> wrote: > > > > > > > The bug is that, while generating the list of declared methods, the > > > VM > > > > > > would initialize classes found in method arguments. Those classes > > > > > > shouldn't be getting initialized at that point, and initialization > > > > > > ordering problems ensue. > > > > > > I got a copy of the APK (thanks!) and poked at it. I believe this is > > > > > the same bug. > > > > > > When the app launch stalled a sent the process a "kill -3" and pulled > > > > > the stack trace out of /data/anr/traces.txt. The two interesting > > > > > threads are: > > > > > > "main" prio=5 tid=3 WAIT > > > > > | group="main" sCount=1 dsCount=0 s=N obj=0x4001d520 self=0xbc60 > > > > > | sysTid=1086 nice=0 sched=0/0 handle=-1343996920 > > > > > at java.lang.Class.getDeclaredMethods(Native Method) > > > > > - waiting on <0x1a8598> (a java.lang.Class) > > > > > at java.lang.ClassCache.getDeclaredPublicMethods(ClassCache.java: > > > > > 166) > > > > > at java.lang.ClassCache.getDeclaredMethods(ClassCache.java:179) > > > > > at java.lang.ClassCache.findAllMethods(ClassCache.java:249) > > > > > at java.lang.ClassCache.getFullListOfMethods(ClassCache.java:223) > > > > > at java.lang.ClassCache.getAllPublicMethods(ClassCache.java:204) > > > > > at java.lang.Class.getMethod(Class.java:1006) > > > > > at com.google.protobuf.GeneratedMessage.getMethodOrDie > > > > > (GeneratedMessage.java:900) > > > > > ... > > > > > > "Graphics" prio=5 tid=19 WAIT > > > > > | group="main" sCount=1 dsCount=0 s=N obj=0x43748ef8 self=0x1a4878 > > > > > | sysTid=1094 nice=0 sched=0/0 handle=1722776 > > > > > at com.ZZZ.Level$Map.<clinit>(Level.java:~1978) > > > > > - waiting on <0x146768> (a java.lang.Class) > > > > > at com.ZZZ.Level$LoadedAnnouncement.<init>(Level.java:-1) > > > > > at com.ZZZ.Level$LoadedAnnouncement.<clinit>(Level.java:2586) > > > > > at java.lang.Class.getDeclaredMethods(Native Method) > > > > > at java.lang.ClassCache.getDeclaredPublicMethods(ClassCache.java: > > > > > 166) > > > > > ... > > > > > > The're both under getDeclaredMethods, and they're both waiting on a > > > > > Class object monitor (but not the same class). The Graphics thread is > > > > > doing a couple layers of class initialization that it shouldn't be > > > > > doing at that point. It's possible we've deadlocked on class init. > > > > > > I tried it twice and ended up in the exact same place both times. > > > > > With the bug fix in place it started up every time. > > > > > > This problem will go away in a future release, but for now you can > > > > > work around it by forcing initialization to happen earlier. The > > > > > easiest way to do this is to call Class.forName(String className) > > > > > early in the app start sequence. Start with Level$Map and Level > > > > > $LoadedAnnouncement and see if that cures it. > > > > > > For anyone building their own VM, you can see the patch inhttp:// > > > code.google.com/p/android/issues/detail?id=3005. > > > -- > > Dianne Hackborn > > Android framework engineer > > [email protected] > > > Note: please don't send private questions to me, as I don't have time to > > provide private support, and so won't reply to such e-mails. All such > > questions should be posted on public forums, where I and others can see and > > answer them. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
