- 11 May, 2015 1 commit
-
-
Jeff Davidson authored
Bug: 20636336 Change-Id: I303d712967f9885f7c3082d00f961f8ab93a6aed
-
- 05 May, 2015 1 commit
-
-
Andre Eisenbach authored
Change-Id: I845ee1ab1005d25c8d77a8c2ed801c0f7b7c847b
-
- 28 Apr, 2015 9 commits
-
-
Charles Munger authored
When a MessageNano containing a String is serialized into a buffer that is too small to contain it, and the buffer's boundary happens to be where the string field's length delimiting varint is serialized, and the string's length and 3*length have the same length when encoded as a varint, an IllegalArgumentException is thrown rather than an OutOfSpaceException. Github issue: https://github.com/google/protobuf/issues/292 Change-Id: If478d68cf15bfd0662252d008e42b2bf1ff1c75e
-
Brian Duff authored
It turns out dex (apparently) was inlining these protected final methods from ExtendableMessageNano into every message class. Removing these methods from the base class and inlining their code reduces the method count by 2 methods / message when the store_unknown_fields option is on. Change-Id: I0aa09f2016d39939c4c8b8219601793b8fab301f
-
Shai Barack authored
Change-Id: Ie2a9e36276ac35e10b3f8d379b5742d50a0374e9
-
Kweku Adams authored
When building, some instances expect createMessageTyped to have the signature (int, Class, long), while others expect (int, Class, int). Simply having the former signature meant that builds expecting the latter would fail. This is a cherrypick of change b2a9d4321578139677c146ce37eba5e27e8f5c79 from master. Change-Id: Ib02dbf66173510f4edea32c7b43e82c1a7a38aa2
-
Brian Duff authored
Change-Id: I85563b74237d38c1e447b7286f5f6e62d57e3d63
-
Brian Duff authored
Upstreamed from Another Place (cr/57247854). Change-Id: I2aaf59544c0f5ae21a51891d8a5eeda1dc722c90
-
Brian Duff authored
Forgot to update these in https://android-review.googlesource.com/#/c/109809/ Change-Id: I53f838e2f134f53964161d9620d5ead00c4a3939
-
Charles Munger authored
Measuring the serialized size of nano protos is now a zero-alloc operation, and serializing a proto now allocates no memory (other than the output buffer) instead of O(total length of strings). Change-Id: Id5e2ac3bdc4ac56c0bf13d725472da3a00c9baec Signed-off-by: Charles Munger <clm@google.com>
-
Brian Duff authored
Previously, extensions with field numbers greater than 268435455 would result in a compile time error in generated code that looks something like this: Foo.java:3178: error: integer number too large: 3346754610 3346754610); This is because we were trying to represent the tag number (an unsigned int) using a java int constant, but java int constants are signed, and can't exceed Integer.MAX_VALUE. Fixed by declaring it as a long instead, and casting it down to an int in the implementation. This is safe, because the tag value always fits in 32 bis. Change-Id: If2017bacb4e20af667eaeaf9b65ddc2c30a7709f
-
- 02 Apr, 2015 2 commits
-
-
Tamir Duberstein authored
-
Tamir Duberstein authored
-
- 19 Feb, 2015 2 commits
- 17 Feb, 2015 1 commit
-
-
Jisi Liu authored
-
- 07 Feb, 2015 1 commit
-
-
Jisi Liu authored
-
- 06 Feb, 2015 4 commits
- 05 Feb, 2015 1 commit
-
-
Jisi Liu authored
override the existing one even for message types.
-
- 04 Feb, 2015 2 commits
- 03 Feb, 2015 3 commits
- 27 Nov, 2014 1 commit
-
-
Feng Xiao authored
-
- 19 Nov, 2014 1 commit
-
-
Feng Xiao authored
-