I don't know anything about protobufs, just that these are the classes the developers use.
On Thu, Jul 23, 2009 at 8:31 PM, Micah <[email protected]> wrote: > > 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. > > > -- 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 -~----------~----~----~----~------~----~------~--~---
