NDK libraries should not be linked in to platform code, so create a
separate version for the platform that is linked against libc++
instead of the NDK STLs.
Bug: 15193147
Change-Id: I3935e5dd3bd99676772a4b9681e275ef3601b855
This will facilitate an upgrade to 2.6.0 and future versions without
breaking applications which have a hardcoded dependency on 2.3.0. The
existing make rules have been renamed to omit the version code.
The prebuilts were built from a tree at commit
9be7e7401174d75e87e21fdc5f43549594a714bb.
Change-Id: I90cf7f029217c8dc63a4b38252025c6b725d72a5
This CL adds the "parcelable_messages" option. When enabled, all
generated message classes will conform to the Android Parcelable
contract. This is achieved by introducing a new parent class for
generated classes which implements the required functionality.
Since the store_unknown_fields option also makes use of a superclass,
ExtendableMessageNano, we have two versions of the new Parcelable
superclass: one extending MessageNano, and one extending
ExtendableMessageNano. These classes are otherwise identical.
As these classes depend on Android framework jars, they are not
included in the host .jar build of the nanoproto library.
Finally, add a test suite for running tests of Android-specific
functionality, as this cannot be done on a desktop JVM.
Change-Id: Icc2a257f03317e947f7078dbb9857c3286857497
You can use the processor option store_unknown_fields to switch
this support on:
aprotoc --javanano_out=store_unknown_fields=true:/tmp/out
A separate option for extensions isn't required. Support
for unknown fields must be turned on to allow storing and
retrieving extensions, because they are just stored as
unknown fields. If unknown fields are switched on, extension
related code will be generated when a proto message includes
an extension range, or an extension is encountered.
By default, store_unknown_fields is false. No additional
code is generated, and the generator will error out if protos
contain extension ranges or extensions.
Change-Id: I1e034c9e8f3305612953f72438189a7da6ed2167
Like micro protobufs except:
- No setter/getter/hazzer functions.
- Has state is not available. Outputs all fields != their default.
- CodedInputStream can only take byte[] (not InputStream).
- Repeated fields are in arrays, not ArrayList or Vector.
- Unset messages/groups are null, not "defaultInstance()".
- Required fields are always serialized.
To use:
- Link libprotobuf-java-2.3.0-nano runtime.
- Use LOCAL_PROTOC_OPTIMIZE_TYPE := nano
Change-Id: I7429015b3c5f7f38b7be01eb2d4927f7a9999c80
Adding new version of cpp library,
'libprotobuf-cpp-2.3.0-full-gnustl-rtti'. Previously, c++ code
compiled against gnustl couldn't link with this library - having
both gnustl and stlport in same binary leads to nasty conflicts.
Bug: 7484202
Change-Id: Ic4fbbfc2839c4ce88bf605cf3d9cca47b146f965
With gLucid protoc is installed in the base system, by renaming
our version there will be no confusion about which compiler is
being used.
Change-Id: I975e29e4444af9467c9b9600d5a2e7027f4046ae
We need this to generate code for .proto files that have
been added to external/chromium (see change I6960c18d).
Change-Id: Ic7a78273ee4f066680039d2f724e658a84869621
Also, have all the libraries follow the same naming convention so
rename com.google.protobuf.micro library to libprotobuf-java-2.3.0-micro.
Change-Id: I7c2a7d883a17f9a6d084ce4cac9601e344e416bf
The host's stl library conflicts with stlport, so we need to exclude
stlport from inclusion in the build if we're targeting the simulator.
Change-Id: Ib4da6140f4b8abb271d8e67636ccec2a796c8c5a
Added android/config.h which will be used to configure
android builds of libraries. Currently I've undef HAVE_HASH_MAP
and HAVE_HASH_SET as the versions in stlport generated compile
errors.
Updated .gitignore to be more selective on what it ignores so
android/config.h wouldn't be ignored.
Change-Id: I53f3636121db2c6017491a37998b816aaf0cab5d
