When adding a Google Cloud Endpoint backend to a Android app using the Google App Engine Java Module Template, two classes (amongst other things) are added to the project.
We are then encouraged to modify these classes to our own requirements. So, I decided to delete the model class (MyBean) and the endpoint class (MyEndpoint) and replace them with my own classes. When I tried to rebuild/clean the project, I get the error message:
Error:Execution failed for task ':backend:appengineEndpointsGetClientLibs'.
There was an error running endpoints command get-client-lib:
<package-name>.MyEndpoint
I looked for a couple of hours for a solution to this problem until I found the cause.So I decided to share it since this question does not even exist on SO (Please correct me if I am wrong)
Go to backend\src\main\webapp\WEB-INF\web.xml
In the web.xml file, look for the init-param and change the parameter value to the new endpoint class you've just added.
<init-param>
<param-name>services</param-name>
<param-value>com.mycompany.backend.New-Endpoint-Class-Name</param-value>
</init-param>
Rebuild the project and everything should be just fine.
Related
I'm getting the below error:
Failed to find a code-generated model provider.
AWS amplify code which throwing this error:
Amplify.addPlugin(new AWSApiPlugin());
Amplify.addPlugin(new AWSDataStorePlugin());
Amplify.configure(context);
I am following the below tutorials:
https://docs.amplify.aws/start/getting-started/generate-model/q/integration/android
https://docs.amplify.aws/cli/graphql-transformer/overview
I have tried generating models and models get generated successfully but still while running the app I am getting above exception.
When you generate models, you should expect to find various code-generated files in your application project. One of them will be app/src/main/java/com/amplifyframework/datastore/generated/model/AmplifyModelProvider.java.
When you build your app, Android Studio will compile that java file into a class file, and include it into your binary.
At runtime, on the phone, the AWSDataStorePlugin() constructor will attempt to find that same AmplifyModelProvider by means of reflection.
I would verify that:
You do actually have the code-generated AmplifyModelProvider;
It is being built successfully;
It is not being stripped out by ProGuard/R8 minification.
If you're still not able to get it working, just use the one-argument version of the AWSDataStorePlugin(...) constructor, instead. That version allows you to explicitly specify the model provider, and does not use runtime reflection.
Amplify.addPlugin(AWSDataStorePlugin(AmplifyModelProvider.getInstance()))
Your datasource needs to be updated:
Try running modelGen, then amplifyPush tasks:
Category
Resource name
Operation
Provider plugin
Api
amplifyDatasource
Update
awscloudformation
I've trained a TensorFlow model that among other things performs input preparation involving a tf.cos operation. I've now integrated this model into an Android application, but it cannot perform inference and produces an error No OpKernel was registered to support Op 'Cos' (full error below).
What I've tried:
I've built a selective registration header and made sure that ops_to_register.h contains the Cos operator
I've rebuilt libtensorflow_inference.so as suggested in a related TensorFlow issue while making sure that ops_to_register.h is being used while building the .so file
I placed the new libtensorflow_inference.so file in my app's app/src/main/jniLibs/<architecture> while makings sure that the new .so file is being used by the app
I still get the same error.
Also, not sure if this is related, but cwise_op_cos.cc is missing in tf_op_files.txt and BUILD.
Is there something I'm doing wrong? How do I get the tf.cos operation to work on Android?
Here's the relevant excerpt from the error:
java.lang.IllegalArgumentException: No OpKernel was registered to support Op 'Cos' with these attrs. Registered devices: [CPU], Registered kernels:
<no registered kernels>
[[Node: stft/hann_window/Cos = Cos[T=DT_FLOAT](stft/hann_window/truediv)]]
at org.tensorflow.Session.run(Native Method)
at org.tensorflow.Session.access$100(Session.java:48)
at org.tensorflow.Session$Runner.runHelper(Session.java:298)
at org.tensorflow.Session$Runner.run(Session.java:248)
at org.tensorflow.contrib.android.TensorFlowInferenceInterface.run(TensorFlowInferenceInterface.java:228)
at org.tensorflow.contrib.android.TensorFlowInferenceInterface.run(TensorFlowInferenceInterface.java:197)
at org.tensorflow.contrib.android.TensorFlowInferenceInterface.run(TensorFlowInferenceInterface.java:187)
It turns out that it is indeed necessary to add these commands to the BUILD (tensorflow/core/kernels/BUILD) file manually.
So, for example, to include tf.cos opperation into your libtensorflow_inference.so you need to do the following:
Make sure || isequal(op, "Cos") is in the ops_to_register.h file (see my explanation above)
Add cwise_op_cos.cc to android_extended_ops_group1 filegroup in tensorflow/core/kernels/BUILD
bazel build //tensorflow/contrib/android:libtensorflow_inference.so ... for the right architecture
Later I even found that one of the TensorFlow developers suggested that hacking the BUILD file is the recommended way in this case :/
Android only builds a subset of the ops, You need to add the ops that
you need that are not in the "commonly used set" by hacking the build
files for your needs.
Source: https://github.com/tensorflow/tensorflow/issues/11804#issuecomment-318415228
I hit this error and found no hits for the error message, so I thought I'd share the solution I came up with to save anyone else facing the problem repeating my work.
When writing a new Android library (apklib) for use in a (large) application, I'm getting the following error during dexing when I add my new project as a dependency:
trouble writing output: Too many field references: 70185; max is 65536.
You may try using --multi-dex option.
References by package:
<...long list of packages with field counts elided...>
The particular build step it fails on is:
java -jar $ANDROID_SDK/build-tools/19.0.3/lib/dx.jar --dex \
--output=$PROJECT_HOME/target/classes.dex \
<... long list of apklib and jar dependencies elided ...>
Using --multi-dex as recommended by the error message might be a solution, but I'm not the owner of the application project and it already has a large complex build process that I would hesitate to change regardless.
I can reproduce this problem with a no-op test library project that has literally no fields, but in the error output it's listed as having 6000+ fields. Of the packages listed in the error output, there are a handful with similar 6k+ field counts, but then the vast majority have more plausible <1k field counts.
This problem is similar to the "Too many methods" problem that Facebook famously hacked their way around. The FB solution seems insane, and the only other solutions I've found (e.g., this Android bug ticket, or this one, this SO answer, this other SO answer) all involve changing the main app's code which is well beyond the scope of what I want to do.
Is there any other solution?
The solution was to change the package in the AndroidManifest to match the main application's package.
A manifest like this:
<manifest package="com.example.testlibrary" ...
resulted in 6k+ fields and build failure. Changing it to match the main application's package
<manifest package="com.example.mainapplication" ...
resulted in the project building successfully.
Note that only the package in the manifest is changing, I did not make any changes to the library's Java source or its layout (the Java package was still com.example.testlibrary with directory structure to match).
I hypothesize that the different package name is causing all the Android fields to be included again under that package. All the packages in the error listing with 6k+ fields had a different package name than the main application.
I also (later, grr), found this blog post which details the same problem and the eventual same solution.
I'm trying to create a new Google App Engine application.
Within a brand new Android project, I added an App Engine project and all seems well. Now when trying to generate an endpoint for a class via Google > Generate Cloud Endpoint it has a number of Unexpected Exception.
Here are some of the exceptions.
java.lang.IllegalArgumentException: Project MyApp is not a web-app project
and
org.eclipse.core.runtime.CoreException: MyApp is not configured as a web application
This doesn't seem to make sense, it's an Android app but I may be mistaken with how it should act.
How do I resolve these errors with Eclipse
I figure someone else is bound to make the same bonehead mistake I did, so I'll answer my own question instead of deleting my shame in case it can help others.
Basically this error message happens when following https://developers.google.com/eclipse/docs/endpoints-addentities and you generate the endpoint class in the wrong project.
When you create a Google App Engine powered Android app, you will have at least two projects: MyApp and MyApp-AppEngine. You need to put your entity class into the MyApp-AppEngine project and NOT your MyApp project.
If you place your class within MyApp and generate the endpoint classes that way, you'll end up confusing Java / Eclipse / yourself / etc. It will then give you the errors
java.lang.IllegalArgumentException: Project MyApp is not a web-app project
and
org.eclipse.core.runtime.CoreException: MyApp is not configured as a web application
I am trying to use the EWS Java API v1.1.5 (http://archive.msdn.microsoft.com/ewsjavaapi) in an Android application, and have run into a number of issues.
I downloaded the source, and followed the instructions provided to compile the EWS Java API in Eclipse. In those instructions you are told to download and
add the following pre-requiste jar file dependencies:
commons-codec-1.4.jar
commons-httpclient-3.1.jar
commons-logging-1.1.1.jar
jcifs-1.3.15.jar
I did this, and followed the build instructions with produced the following jar files:
EWSAPI-1.1.0.jar
EWSAPIWithJars-1.1.0
Next, I built a brand new Android application, added the appropriate permissions to the manifest, and then added the following source to the primary activity's OnCreate:
ExchangeService service = new ExchangeService();
ExchangeCredentials credentials = new WebCredentials("emailaddress", "password");
service.setCredentials(credentials);
try
{
service.autodiscoverUrl("emailaddress", this);
}
catch (Exception e)
{
e.printStackTrace();
}
I first tried running this application with the EWSAPI-1.1.0.jar file as a dependency. When I did that, I obtained the following fatal error:
Uncaught handler: thread main exiting due to uncaught exception
java.lang.NoClassDefFoundError:
org.apache.commons.httpclient.MultiThreadedHttpConnectionManager at
microsoft.exchange.webservices.data.ExchangeServiceBase.(Unknown
Source) at
microsoft.exchange.webservices.data.ExchangeServiceBase.(Unknown
Source) at
microsoft.exchange.webservices.data.ExchangeService.(Unknown
Source) at
com.meshin.exchange.ExchangeDiscoveryActivity.onCreate(ExchangeDiscoveryActivity.java:40)
From what I've researched, it seems like this error is being generated because Android comes with the Apache HttpClient 4.0, which doesn't appear
to have the MultiThreadedHttpConnectionManager class anymore.
If I instead remove the EWSAPI-1.1.0.jar, and instead use the EWSAPIWithJARS-1.1.0.jar file as a dependency, I get the following error:
VFY: unable to resolve static method 908: Ljavax/xml/stream/XMLOutputFactory;
newInstance()Ljavax/xml/stream/XMLOutputFactory;
VFY: dead code 0x0008-006a in L
microsoft/exchange/webservices/data/EwsUtilities;.formatLogMessage
(Ljava/lang/String;Ljava/lang/String;) Ljava/lang/String;
VFY: unable to find class referenced in signature (Ljavax/xml/stream/XMLStreamWriter;)
And then eventually...
FATAL EXCEPTION: main java.lang.VerifyError:
microsoft.exchange.webservices.data.AutodiscoverService at
microsoft.exchange.webservices.data.ExchangeService.getAutodiscoverUrl(Unknown
Source) at
microsoft.exchange.webservices.data.ExchangeService.autodiscoverUrl(Unknown
Source) at
com.meshin.exchange.ExchangeDiscoveryActivity.onCreate(ExchangeDiscoveryActivity.java:41)
I am assuming because now I am including the HttpClient 3.1 jar and it is conflicting with the HttpClient 4.0 jar included with the Android libraries.
My question is if there is a way for me to use the EWS Java API in an Android project without having to re-write the parts of it which reference
HttpClient 3.1-specific things which are no longer in 4.0.
You can use microsoft's EWS api for android by doing the following steps,
download the source code available in the URL,
http://archive.msdn.microsoft.com/ewsjavaapi
EWSJavaAPI_1.1.5.zip
Make the changes to above api to work for JDK 1.4 in eclipse like remove override annotations e.t.c
Download source code of javax.* package available in below URL,
http://www.java2s.com/Code/JarDownload/jsr173/jsr173_1.0_src.jar.zip
Download source code of stax api available in below URL,
http://dist.codehaus.org/stax/distributions/stax-src-1.2.0.zip
Keep all the sources under the single java project in eclipse
Open the project explorer and select the package which are starts with "javax" and rename to your company name eg: com. Note: Eclipse will ask for all the naming contexts will change then click OK.
Export all the java sources to one single jar file.
Then You good to go to use the jar in Android application with out any problems.
I used the same way explained above and it worked in android application 100% perfectly.
This isn't a useful answer but I've also been struggling to look at the EWS API over the last couple of weeks, with no success.
The main issue I've found is it references a lot of the javax APIs which aren't on Android. There's a hack you can find that explains how to "re-class" these but I've not got it working yet; in addition, the DnsClient references some namespaces that jarsearches only return for rt.jar - the main runtime. And including this in an Android app would just be crazy!
Before finding the API I was trying to use KSOAP to communicate with EWS but again ran into problems - you need to be able to do NTLM and SSL and I couldn't find any way of combining all these with KSOAP in any simple way.
The EWS API looks the way to go (why re-invent the wheel) but getting it working on Android looks very tricky (if not impossible)
Please check this library for the solution