I am using the latest AS from the canary channel, and the ndk that goes with it.
I modified my Android project to suit, and my app (including JNI) builds and runs properly.
I have not (yet) allowed the tools to automatically handle building the JNI part. Lots of special sauce in the existing makefiles, so that would be a lot of work. So I don't have an android.ndk section in my build file. I also have a single gradle.build file.
My debug build type looks like this:
android.buildTypes {
debug {
isMinifyEnabled = false
proguardFiles += file('proguard-rules.txt')
isDebuggable = true
isJniDebuggable = true
}
}
I added a native run configuration. When I try to debug it, I get an exception like LLDB server not found.
If I switch the to gdb, I get a different exception. Any thoughts?
A couple of JNI samples like Teapot and hello-jni are working fine.
Here is the LLDB exception:
LLDB server not found
java.lang.Throwable
at com.intellij.openapi.diagnostic.Logger.error(Logger.java:115)
at com.android.tools.ndk.run.lldb.AndroidLLDBDebuggerContext.launchLLDBServer(AndroidLLDBDebuggerContext.java:66)
at com.android.tools.ndk.run.lldb.AndroidLLDBDebuggerContext.startServer(AndroidLLDBDebuggerContext.java:55)
at com.android.tools.ndk.run.AndroidNativeDebugRunner$NativeDebugLauncher.launchDebug(AndroidNativeDebugRunner.java:109)
at org.jetbrains.android.run.AndroidRunningState.launchDebug(AndroidRunningState.java:835)
at org.jetbrains.android.run.AndroidRunningState.clientChanged(AndroidRunningState.java:814)
at com.android.ddmlib.AndroidDebugBridge.clientChanged(AndroidDebugBridge.java:879)
at com.android.ddmlib.Device.update(Device.java:721)
at com.android.ddmlib.Client.update(Client.java:938)
at com.android.ddmlib.HandleAppName.handleAPNM(HandleAppName.java:112)
at com.android.ddmlib.HandleAppName.handleChunk(HandleAppName.java:65)
at com.android.ddmlib.MonitorThread.callHandler(MonitorThread.java:414)
at com.android.ddmlib.MonitorThread.processClientActivity(MonitorThread.java:322)
at com.android.ddmlib.MonitorThread.run(MonitorThread.java:263)
I'm afraid you need compile your C++ codes with gradle but not makefile. LLDB server will be generated with gradle automatically. Android studio didn't support any other external build systems(e.g. Makefile) yet.
We have attach the debugger as java not as native. As for you have mentioned ndk it should use native. but any how try this method to avoid debugger detaching and app gets killed automatically.
Related
The following was done with Android Studio 3.4, Android Gradle Plugin 3.3.2 and Gradle 4.10.3.
In the build.gradle file, I have configured some unit test options like this:
android {
testOptions {
unitTests.all {
systemProperty "debug","true"
}
}
}
I do have a test function that tries to read this property:
package com.demo;
public class SysPropTestDemo {
#Test
public static void dumpSysProps() {
System.out.println("sysprop(debug)=" + System.getProperty("debug"));
}
}
When run via command line gradlew test --test com.demo.SysPropTestDemo I will get the property debug set correctly to true. If I run the same test via Android Studio without setting any options, the value shown will be null.
In order to get the same result from Android Studio, I explicitly have to enter some values in the "Run/Debug Configurations" panel, i.e something like -Ddebug=true in the VM options.
Now this is a trivial example, but what I really want to do, is to add some path to the java.library.path property in order to be able to load a JNI library compiled within the project. (I do need to write some tests that make use a modified SQLite lib, so not using JNI is not an option here)
It does work when setting additional options, but I think this is very inconvenient, since I can't enter a variable based value in the configuration options (or at least, I don't know how to). To sum it up: when setting or changing values, I do have to go through a bunch of config screens where I would really prefer to have one place in a config file.
Shouldn't Android Studio somehow make use of the values specified in the build.gradle file? If not, the docs don't make it clear that the testOptions.unitTests.all settings can only be used via gradlew invocation.
Skybow,
I feel you have two questions
1. How to load jni lib for androidTest(not for 'test[non instrumented unit tests])
- copy your jni library in corresponding folder [JNI libraries: [app/src/androidTestFLAVORNAMEDebug/jniLibs]
- load your jni library
static {
try {
System.loadLibrary("xyzjni");
} catch (Exception e) {
Logger.error("Exception on loading the jni library : " + e.getMessage());
}
}
2. How to make android studio use your config variables defined for unitTests.
- It would have great if some text file is there which has all configs.
- Or it is part of build.gradle
- I don't have any detail on this.
I am trying to build my Unity project with Jenkins.
Created a BuildScript with the following calls (not all is shown):
BuildPlayerOptions options = new BuildPlayerOptions();
options.scenes = new string[] { "Assets/game.unity" };
options.targetGroup = BuildTargetGroup.Android;
options.target = BuildTarget.Android;
options.locationPathName = "/Users/Admin/my.apk";
BuildPipeline.BuildPlayer(options);
When I call this build from a local shell, the build works great and an apk is created.
When I try to call it from Jenkins using the Unity3d plugin, I get a strange compilation error which seems to be related to a missing UNITY_ANDROID directive. So basically code inside
#if UNITY_ANDROID
...
#endif
Is not called.
Is there any reason why when my code is compiled from the Jenkins build, the above directive (and others I guess) are not defined automatically?
So I was able to solve this one, by trial and error.
It appears that when I ran the build with a -projectPath, Unity does not recognise the platform and set the directive.
Adding the -buildTarget Android command line to the build, solves this issue.
How do I get rid of console logs from an ionic 2 release application?
I am developing an ionic 2 app. When I build the release apk and run on a device, I can still attach to the process from chrome://inspect, and view console logs. I have tried removing the cordova-plugin-console, but that makes no difference.
Edit: I found a package that can remove console logs: https://www.npmjs.com/package/remove-console-logs
Just not sure how I can use it to automatically remove them when I build release. Please help.
Thanks.
You can use uglifyjs.config.js for drop all console logs when is a production build.
1 . Copy uglifyjs.config.js from node_modules into your project folder
2 . In the new config file set the flag drop_console to true if production
var isProduction = process.env.IONIC_ENV === 'prod';
...
compress: {
drop_console: isProduction
}
3 . Set your custom configuration in the package.json
"config": { "ionic_uglifyjs": "uglifyjs.config.js" },
And that's all !
If you can still connect with the debugger then it is not a release build - sounds like you may be unintentionally installing the debug build OR connecting to some other app.
EDIT; Above is not necessarily true - there are instances where you can debug the js/html/css content via chrome in a release build ; specifically if the webview debuggability flag is set in code / not set by the build system etc. - this flag is seperate from the application debug flags so if not properly set you will be able to debug a "release" build / not be able to debug a "debug" build - see remote debugging webviews.
END OF EDIT.
( note you have to sign a release build before it will install )
Is it possible the release install failed and you're still looking at a previous debug build ?
Assuming you have a release build and can't connect to see logs via chrome inspect then ;
console.log calls will still be in the release build unless you comment them out - and possibly visible in other ways eg. android tools sdk\tools\monitor - The only way to be sure they aren't visible is to comment them out. You could use something like ;
console.log = function(){} ;
at the end of your device ready function after any plugins have done anything they're likely to do - though there's still no 100% guarantee with this as a badly behaving 3rd party plugin or library might reassign it later and then your calls will still happen - to be absolutely sure you will need to comment them out.
Have you tried remove console logs ?
cordova plugin rm cordova-plugin-console
Then
cordova build --release android
I'm having a ton of difficulty trying to get Gradle to compile a debug version of my JNI code through NDK build. I've set the debug build to be debuggable in the build.gradle file like so:
buildTypes {
debug {
debuggable true
jniDebuggable true
}
}
I can confirm that the switches are taking effect if I check out Build/Edit Build types. However, once I check the ndkBuild_build_command.txt file inside of the .externalNdkBuild directory, I notice the following entries:
NDEBUG=1
APP_PLATFORM=android-9
I can confirm that my JNI code does not seem to be debuggable. Even though the breakpoints trigger, variables all show "variable not available" in LLVM.
Any ideas as to why NDEBUG is turned on even in a debug build? As a sidenote, I also have no idea where the android-9 platform is entering in... I'm not setting that myself anywhere that I could find.
If you use Android Studio 2.2 with externalNativeBuild, you can set APP_OPTIM=debug in your Application.mk or NDK_DEBUG=1 through parameters override, e.g.
externalNativeBuild {
ndkBuild {
arguments "NDK_DEBUG:=1"
}
}
I have a React Native project and it runs successfully on both simulators and devices for iOS.
However, for Android, it runs successfully on simulators without any problems, but when run on devices as a Release build, it gives me this error:
Requiring unknown module "react-native-safari-view".
I tried npm cache clean and npm install several times, but it does not work.
The module exists in node_modules folder and it is also under dependencies in package.json.
What could be the cause of this? Why does it happen only in Release builds?
Update: If this is difficult to fix, is it possible to generate a signed apk with the js bundle included in dev mode?
It is because react-native-safari-view module is not designed for Android.
Check this out: (inside index.android.js file in GitHub)
var SafariViewManager = {
test: function() {
warning('Not yet implemented for Android.');
},
isAvailable: function() {
...
}
};
Maybe you are initiating a SafariViewManager object and calling other functions like show() in index.ios.js without checking it isAvailable()?