* Revert "Revert "[BinderTransport] Allow finding Java class using custom class finder (#28348)" (#28496)"
This reverts commit ecf6a7fa95.
* Add missing include directives
In some some situation it is not feasible to invoke
`InitializeBinderChannelJavaClass` in non-native threads.
And the intended way to find Java class is through class loader cached
at program initialization.
This commit adds a new API that accepts a class finder from user and
uses the function to find and cache binder transport Java util class.
* Plumb subject field and add to authz flow.
* formatting
* Test on empty principal
* resolving comments
* resolving comment
* update subject check in test
* Check if memory owner available prior to polling it
The transport may drop the memory owner during its destruction sequence
* tcp_fix
* Revert "Revert "New resource quota integration (#27643)" (#28014)"
This reverts commit 0ea2c37263.
* clang-format
* fix-path
* fix
* Reintroduce the EventEngine default factory
An application can provide an EventEngine factory function that allows
gRPC internals to create EventEngines as needed. This factory would be
used when no EventEngine is provided for some given channel or server,
and where an EventEngine otherwise could not be provided by the
application. Note that there currently is no API to provide an
EventEngine per channel or per server.
I've also deleted some previous iterations on global EventEngine and
EventEngine factory ideas. This new code lives in a public API, and
coexists with iomgr instead of being isolated to an EventEngine-specific
iomgr implementation.
* add proper namespaces, and fix description
* put factory functions in their own file (for replaceability)
* add synchronization
* generate_projects.sh
* extract event_engine_base and event_engine_factory targets
Also separate iomgr/event_engine files in the BUILD, with comments
* gpr_platform
* move all EE factory declarations to event_engine_base
Makes internal hackery easier.
* add missing deps
* reorder dep alphabetically
* comment style change
* Assert Android API >= v21
This precedes a change that would otherwise break on older Android APIs,
but in a more obvious way.
* error if __ANDROID_API__ is not defined
* update all Andriod minSdkVersions to 21
* csharp experimental: android-19 to 21
Due to limitation of JVM, when user want to create binder channel in
threads created in unmanaged native code, they will need to call this
new API first to make sure Java helper classes can correctly be found.
Unused code in jni_utils.cc are also cleaned up in this commit
* [BinderTransport] Avoid depending on NdkBinder at compile time
We would like to make it possible to use BinderTransport in a APK that
has min sdk version lower than 29 (NdkBinder was introduced at 29)
We copies constants and type definitions from Ndk headers, creates a
same name wrapper for every NdkBinder API we use in
grpc_binder::ndk_util namespace.
We will try to load libbinder_ndk.so and resolve the symbol when the
NdkBinder API wrappers are invoked.
* regenerate projects
* Add GRPC_NO_BINDER guard
* Expose experimental binder transport API
New headers are added
`grpcpp/create_channel_binder.h `: interfaces for creating client
channel
`grpcpp/security/binder_credentials.h`: interfaces for binder server
credentials
`grpcpp/security/binder_security_policy.h`: interfaces for binder
security policy, which is used by both server and client. Individual
security policies are merged into this single header.
Users can now depend on the `grpc++_binder` target to use the headers
listed above.
* Regenerate projects
This introduces the new `Closure` type, and new cancellation semantics.
I've also fixed a few bugs in the EventEngine iomgr implementation that
had gone unnoticed.
* Fix OOM issues in qps tests
* Add more verbose logging.
* Fix clang error
* Fix race between IsCancelled and Read
* Fix build errors from using bool in C code
This commit adds a new symbol GPR_SUPPORT_BINDER_TRANSPORT to
port_platform.h
This will help avoid surprising compilation failure when compiled with
old NDK or low API level
It was determined that an explicit Shutdown method is not necessary, and further, it can be challenging to implement efficiently in some cases. Instead, EventEngines are expected to clean themselves up upon destruction. Anything that relies on an EventEngine's existence must coordinate itself to ensure the engine remains alive for as long as it's needed.
Internal bug b/170934515
In some cases, calling CQ::Next will return true without passing up a
new tag value, which is very much illegal. My expectation is that this
is due to messing up between SHUTDOWN and TIMEOUT in lower layer code
that doesn't particularly matter much to most callers, but was being
erroneously checked here.
Ming-Chuan