Fixed
Status Update
Comments
om...@gmail.com <om...@gmail.com> #2
Test with a clean install of Android Studio 3.2 on a fresh Windows installation shows that the last version where this worked properly was 3.2.
It is still possible to upgrade to 3.2.1 and have this feature work. And it is also possible to upgrade using the separately downloaded exe installer android-studio-ide-181.5056338-windows.exe, that will remove the previous version of AS and install a new one. I know... technically there should be no difference but the devil is in the details.
Further research in my Virtual Machine seems to show that if I install AS 3.2 on a clean machine and then try AS 3.4 beta 1 and AS 3.3 as a parallel install (run from a decompressed ZIP file) they both work.
On my main computer an upgrade to 3.3 made things a lot worse (See issue: 123071299), as well as a further upgrade to 3.4 beta1 (See issue: 123071300).
It looks like AS 3.2 creates some kind of a favorable config that all next AS versions can work with. However this is what should have happened on my main computer as I did regularly update AS and I must have had AS 3.2 installed before AS 3.2.1.
What did strike me as odd was what felt that a LOT more "Indexing" was performed when trying the side installations of AS 3.3 and 3.4b1. It could be the VM making things feel slower...
It is still possible to upgrade to 3.2.1 and have this feature work. And it is also possible to upgrade using the separately downloaded exe installer android-studio-ide-181.5056338-windows.exe, that will remove the previous version of AS and install a new one. I know... technically there should be no difference but the devil is in the details.
Further research in my Virtual Machine seems to show that if I install AS 3.2 on a clean machine and then try AS 3.4 beta 1 and AS 3.3 as a parallel install (run from a decompressed ZIP file) they both work.
On my main computer an upgrade to 3.3 made things a lot worse (See issue: 123071299), as well as a further upgrade to 3.4 beta1 (See issue: 123071300).
It looks like AS 3.2 creates some kind of a favorable config that all next AS versions can work with. However this is what should have happened on my main computer as I did regularly update AS and I must have had AS 3.2 installed before AS 3.2.1.
What did strike me as odd was what felt that a LOT more "Indexing" was performed when trying the side installations of AS 3.3 and 3.4b1. It could be the VM making things feel slower...
om...@gmail.com <om...@gmail.com> #3
I double checked... A clean install of 3.2.1 doesn't work.
om...@gmail.com <om...@gmail.com> #4
A clean install of AS 3.3 appears to also be working.
In my case I knew that AS 3.2.1 was last working for me before an upgrade. So I spent a WEEK trying to install AS 3.2.1 in a way that it would work. And that is the one thing that definitely doesn't work.
But I do wish there was some easier way of adding a sample C++ integration when creating a project or later while working on a project. Adding the CMake file, the Gradle bit, a dummy C++ file and Java native function is reasonable effort... But I suppose for people that want to learn how to mix Java and C++ it is very useful to have some code auto-generated by AS and the Gradle native build block added.
In my case I knew that AS 3.2.1 was last working for me before an upgrade. So I spent a WEEK trying to install AS 3.2.1 in a way that it would work. And that is the one thing that definitely doesn't work.
But I do wish there was some easier way of adding a sample C++ integration when creating a project or later while working on a project. Adding the CMake file, the Gradle bit, a dummy C++ file and Java native function is reasonable effort... But I suppose for people that want to learn how to mix Java and C++ it is very useful to have some code auto-generated by AS and the Gradle native build block added.
tg...@google.com <tg...@google.com>
em...@google.com <em...@google.com> #5
I reproduced the "broken interlink" and "Native code is all red" problems using a clean Windows VM and the first set of instructions in comment#1 .
I was able to work around this issue by downgrading to CMake 3.6 (i.e., uninstall 3.10.2 and install 3.6.* from SDK manager). Could you please try this method and let us know if it helped you as well?
I was able to work around this issue by downgrading to CMake 3.6 (i.e., uninstall 3.10.2 and install 3.6.* from SDK manager). Could you please try this method and let us know if it helped you as well?
om...@gmail.com <om...@gmail.com> #6
Will do, first thing in the morning.
om...@gmail.com <om...@gmail.com> #7
I am glad to hear you were able to reproduce the issue. You are correct, my clean installation of AS 3.2.1 indeed had CMake 3.10.2 installed.
The situation has improved. Here is what I did:
- in AS I opened SDK manager
- unchecked CMake 3.10.2
- checked CMake 3.6
- applied the changes (BTW ptaching 3.10.2 to <none> looks silly in SDK manager. Removing: ... would sound and look much better.. it also seems to last VERY long for a delete op)
- Situation was at first unchanged
- then I went for Build -> Refresh linked C++ projects
- and voila, all looks right now and a new test function was also correctly generated (See: AS3.2.1_Cmake3.6_OK.png)
So it looks like newer component should not (always) be installed or offered to be installed by older versions of AS. Perhaps the package xml file should contain a version compatibility vector as well. Newer versions of Gradle in AS 3.2.1 is also a no-go for example and users get a "warning" that a newer version exists. That makes it extra tempting for an upgrade. You can use the same sample to verify. See:https://stackoverflow.com/questions/54267627/unsupported-gradle-method-nativeartifact-getsourcefolders/54311939#54311939 I can file it as a separate issue if you like.
Thank you for looking into the issue and have a great day.
The situation has improved. Here is what I did:
- in AS I opened SDK manager
- unchecked CMake 3.10.2
- checked CMake 3.6
- applied the changes (BTW ptaching 3.10.2 to <none> looks silly in SDK manager. Removing: ... would sound and look much better.. it also seems to last VERY long for a delete op)
- Situation was at first unchanged
- then I went for Build -> Refresh linked C++ projects
- and voila, all looks right now and a new test function was also correctly generated (See: AS3.2.1_Cmake3.6_OK.png)
So it looks like newer component should not (always) be installed or offered to be installed by older versions of AS. Perhaps the package xml file should contain a version compatibility vector as well. Newer versions of Gradle in AS 3.2.1 is also a no-go for example and users get a "warning" that a newer version exists. That makes it extra tempting for an upgrade. You can use the same sample to verify. See:
Thank you for looking into the issue and have a great day.
em...@google.com <em...@google.com> #8
When we run sync, cmake generates a .externalNativeBuild/cmakedebug/x86/android_gradle_build.json file. With CMake 3.10 on Windows, it generates something like this (full file attached):
++++
"stringTable": {
"0": "C:/Users/Emulator Team/AndroidStudioProjects/NativeApp/app/.externalNativeBuild/cmake/debug/x86",
"1": "--target=i686-none-linux-android16 --gcc-toolchain=C:/Android/..../windows-x86_64 -Dnative_lib_EXPORTS --sysroot C:/Android....//sysroot -g -DANDROID -f...",
"2": "--sysroot C:/Android/..../sysroot -g -DANDROID -f.... "
},
"libraries": {
"native-lib-Debug-x86": {
...
"artifactName": "native-lib",
"files": [
{
"src": "C:\\Users\\Emulator Team\\AndroidStudioProjects\\NativeApp\\app\\src\\main\\cpp\\native-lib.cpp",
"flagsOrdinal": 2,
"workingDirectoryOrdinal": 0
}
],
++++
The "flagsOrdinal" value is a pointer to an entry in the stringTable. In this example, I think it's supposed to point to entry "1", but it points to entry "2". When I manually change it to "1" and re-hit "sync" (it won't overwrite the file in this case -- overwrite happens when we do Refresh linked C++ projects), all JNI connections start functioning as expected, i.e.,
1. All native includes are found.
2. Java side native methods are no longer not-found.
3. JNI automatic method creation works.
I'll investigate where we write this flagsOrdinal, and see if it actually is the source of the bug.
++++
"stringTable": {
"0": "C:/Users/Emulator Team/AndroidStudioProjects/NativeApp/app/.externalNativeBuild/cmake/debug/x86",
"1": "--target=i686-none-linux-android16 --gcc-toolchain=C:/Android/..../windows-x86_64 -Dnative_lib_EXPORTS --sysroot C:/Android....//sysroot -g -DANDROID -f...",
"2": "--sysroot C:/Android/..../sysroot -g -DANDROID -f.... "
},
"libraries": {
"native-lib-Debug-x86": {
...
"artifactName": "native-lib",
"files": [
{
"src": "C:\\Users\\Emulator Team\\AndroidStudioProjects\\NativeApp\\app\\src\\main\\cpp\\native-lib.cpp",
"flagsOrdinal": 2,
"workingDirectoryOrdinal": 0
}
],
++++
The "flagsOrdinal" value is a pointer to an entry in the stringTable. In this example, I think it's supposed to point to entry "1", but it points to entry "2". When I manually change it to "1" and re-hit "sync" (it won't overwrite the file in this case -- overwrite happens when we do Refresh linked C++ projects), all JNI connections start functioning as expected, i.e.,
1. All native includes are found.
2. Java side native methods are no longer not-found.
3. JNI automatic method creation works.
I'll investigate where we write this flagsOrdinal, and see if it actually is the source of the bug.
om...@gmail.com <om...@gmail.com> #9
Ha! Cool! "Compression"! :)
You are absolutely right. I can reproduce the problem and use the workaround you described on my end in Android Studio 3.3 (side-by-side install). In my gradle file in the externalNativeBuild cmake block I am forcing the CMake version "3.10.2". (I opted to give AS 3.3 a try on my main development machine in a side-by-side install scenario).
When I previously tried this I noticed the standard C++ native includes (<vector>, <iostream>, ...) were not found (haven't verified 2 and 3).
I inspected the android_gradle_build.json file and as you said, some files had "flagsOrdinal": 1 while others had "flagsOrdinal": 2.
In particular a pattern became apparent: In my project I need to keep some "shared" sources outside of the folder structure of the AS project. So I use a relative path to these sources in my CMake build file. See: AS-CMake_sources.PNG
And for all the cpp files in the shared location I had "flagsOrdinal": 2 while all the cpp files in the "usual" spot in the AS folder structure had the correct "flagsOrdinal": 1 value. This was clearly not the case in your sample project as the native-lib.cpp is inside the AS folder structure.
When I swapped the order of the source file imports in the CMake file to have the ${SHARED_SOURCES} block at the end:
${LOCAL_SOURCES}
${LOCAL_JNI_SOURCES}
${SHARED_SOURCES}
the flagsOrdinal was again pointing to the wrong location only for the files that reside outside of the AS folder structure.
It would be great if CMake would allow relative paths to source files like in my case as this widens the "solution space" for various configuration management challenges.
To summarize:
1. I was able to reproduce and correct the issue the way you described
2. The problem on my end explicitly occurred for sources outside of the AS sources folder structure
Thank you for your time.
P.s.: I see that the "compression" approach is new to CMake 3.10.2 since 3.6.0 generated android_gradle_build.json just uses the usual approach by adding a full flags, src and workingDirectory for each cpp file (which is larger and harder to maintain in sync).
You are absolutely right. I can reproduce the problem and use the workaround you described on my end in Android Studio 3.3 (side-by-side install). In my gradle file in the externalNativeBuild cmake block I am forcing the CMake version "3.10.2". (I opted to give AS 3.3 a try on my main development machine in a side-by-side install scenario).
When I previously tried this I noticed the standard C++ native includes (<vector>, <iostream>, ...) were not found (haven't verified 2 and 3).
I inspected the android_gradle_build.json file and as you said, some files had "flagsOrdinal": 1 while others had "flagsOrdinal": 2.
In particular a pattern became apparent: In my project I need to keep some "shared" sources outside of the folder structure of the AS project. So I use a relative path to these sources in my CMake build file. See: AS-CMake_sources.PNG
And for all the cpp files in the shared location I had "flagsOrdinal": 2 while all the cpp files in the "usual" spot in the AS folder structure had the correct "flagsOrdinal": 1 value. This was clearly not the case in your sample project as the native-lib.cpp is inside the AS folder structure.
When I swapped the order of the source file imports in the CMake file to have the ${SHARED_SOURCES} block at the end:
${LOCAL_SOURCES}
${LOCAL_JNI_SOURCES}
${SHARED_SOURCES}
the flagsOrdinal was again pointing to the wrong location only for the files that reside outside of the AS folder structure.
It would be great if CMake would allow relative paths to source files like in my case as this widens the "solution space" for various configuration management challenges.
To summarize:
1. I was able to reproduce and correct the issue the way you described
2. The problem on my end explicitly occurred for sources outside of the AS sources folder structure
Thank you for your time.
P.s.: I see that the "compression" approach is new to CMake 3.10.2 since 3.6.0 generated android_gradle_build.json just uses the usual approach by adding a full flags, src and workingDirectory for each cpp file (which is larger and harder to maintain in sync).
em...@google.com <em...@google.com> #10
We might be hitting this case:
https://android.googlesource.com/platform/tools/base/+/mirror-goog-studio-master-dev/build-system/gradle-core/src/main/java/com/android/build/gradle/tasks/CmakeServerExternalNativeJsonGenerator.java#570
which can't find the existing stringTable entry #1 on the if-condition, and then falls back to add a stringTable entry #2 instead.
which can't find the existing stringTable entry #1 on the if-condition, and then falls back to add a stringTable entry #2 instead.
om...@gmail.com <om...@gmail.com> #11
It does look like a good candidate. Try placing in a trace value or make a note in the log.
The question is why though. It looks like indexCompilationDatabase doesn't produce a valid hash table from the input parameters. Probably the StringTable is a few strings short? The input for it is nativeBuildConfigValue.stringTable (line 440).
But why is the table correct once written to the json file if it is short initially...?
The question is why though. It looks like indexCompilationDatabase doesn't produce a valid hash table from the input parameters. Probably the StringTable is a few strings short? The input for it is nativeBuildConfigValue.stringTable (line 440).
But why is the table correct once written to the json file if it is short initially...?
em...@gmail.com <em...@gmail.com> #12
I added some logs to android gradle plugin and reproduced the issue you descibed.
Test setup:
Custom built Android Studio and Gradle Plugin 3.5 studio-master-dev head.
Pinned to CMake 3.10.2
Attached log shows the difference between flagsOrdinal values of 1 and 2. Specifically, the following part is interesting:
+++
C:\AndroidStudioProjects\NativeApp>gradlew :app:generateJsonModelDebug
...
target.sourceDirectory = C:/AndroidStudioProjects/NativeApp/app
Source = ../Shared/another.cpp
sourceFile.getPath() = C:\AndroidStudioProjects\NativeApp\app\..\Shared\another.cpp
CompilationDatabaseFlags = {C:\AndroidStudioProjects\NativeApp\app\src\main\cpp\native-lib.cpp=1, C:\AndroidStudioProjects\NativeApp\Shared\another.cpp=1}
Key not found...
CompileFlags = --sysroot C:/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/windows-x86_64/sysroot -g -DANDROID -fdata-sections -ffunction-sections -funwind-tables -fstack-protector-strong -no-canonical-prefixes -mstackrealign -fno-addrsig -Wa,--noexecstack -Wformat -Werror=format-security -stdlib=libc++ -O0 -fno-limit-debug-info -fPIC -Dnative_lib_EXPORTS
Using flagsOrdinal = 2
+++
It shows that compilation database adds the following to the strings table:
C:\AndroidStudioProjects\NativeApp\Shared\another.cpp
But, later, when we search the strings table, we lookup using:
sourceFile = target.sourceDirectory + source
= C:/AndroidStudioProjects/NativeApp/app + ../Shared/another.cpp
= C:\AndroidStudioProjects\NativeApp\app\..\Shared\another.cpp
Hence, the "../" relative path indeed seems to be the problem.
Test setup:
Custom built Android Studio and Gradle Plugin 3.5 studio-master-dev head.
Pinned to CMake 3.10.2
Attached log shows the difference between flagsOrdinal values of 1 and 2. Specifically, the following part is interesting:
+++
C:\AndroidStudioProjects\NativeApp>gradlew :app:generateJsonModelDebug
...
target.sourceDirectory = C:/AndroidStudioProjects/NativeApp/app
Source = ../Shared/another.cpp
sourceFile.getPath() = C:\AndroidStudioProjects\NativeApp\app\..\Shared\another.cpp
CompilationDatabaseFlags = {C:\AndroidStudioProjects\NativeApp\app\src\main\cpp\native-lib.cpp=1, C:\AndroidStudioProjects\NativeApp\Shared\another.cpp=1}
Key not found...
CompileFlags = --sysroot C:/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/windows-x86_64/sysroot -g -DANDROID -fdata-sections -ffunction-sections -funwind-tables -fstack-protector-strong -no-canonical-prefixes -mstackrealign -fno-addrsig -Wa,--noexecstack -Wformat -Werror=format-security -stdlib=libc++ -O0 -fno-limit-debug-info -fPIC -Dnative_lib_EXPORTS
Using flagsOrdinal = 2
+++
It shows that compilation database adds the following to the strings table:
C:\AndroidStudioProjects\NativeApp\Shared\another.cpp
But, later, when we search the strings table, we lookup using:
sourceFile = target.sourceDirectory + source
= C:/AndroidStudioProjects/NativeApp/app + ../Shared/another.cpp
= C:\AndroidStudioProjects\NativeApp\app\..\Shared\another.cpp
Hence, the "../" relative path indeed seems to be the problem.
om...@gmail.com <om...@gmail.com> #13
Aha, the key in the StringTable for "another.cpp" doesn't have enough dots in it. :)
It was pretty close though! I am glad you were able to find the problem. Looking forward to the new build!
Wow, your VM isn't as fast as I imagined it would be. I noticed the generateJsonModelDebug task took more than 21s. I thought I need faster HW, but there isn't a lot of room for improvement. Well, Gradle has come a long way in terms of speed improvements and I am sure it will just get faster over time.
It was pretty close though! I am glad you were able to find the problem. Looking forward to the new build!
Wow, your VM isn't as fast as I imagined it would be. I noticed the generateJsonModelDebug task took more than 21s. I thought I need faster HW, but there isn't a lot of room for improvement. Well, Gradle has come a long way in terms of speed improvements and I am sure it will just get faster over time.
em...@google.com <em...@google.com> #14
The fix will be included in the next Android Studio releases (3.3.2, 3.4 Beta 4, 3.5 Canary 4). Please reopen if you continue to experience the same issue after upgrade.
ma...@gmail.com <ma...@gmail.com> #15
Thanks for you help. Sorry, I didn't intend to hijack this thread for support.
Turned up build output to verbose and seeing something now.
Still not seeing anything _useful_ in the Console though...
Really I am just saying - aapt DOES CRASH on my very vanilla Win XP ADT setup. (As in Windows XP pops a dialogue and tries to send an Error Report to Microsoft).
I can reproduce it if anyone wants me to try anything further.
With verbose build output, below is the last bit of what I see:
Notice the fragmented output line "(new"
Interestingly, it seems to process the implicated menu fine earlier, but blows later amidst unrelated .wav files...
<Lots before this, then: >
...
[2013-11-21 17:39:55 - MyApp] (new resource id say50 from C:\AndroidDev\EclipseWorkspace\MyApp\res\raw\say50.wav)
[2013-11-21 17:39:57 - MyApp] (new
[2013-11-21 17:39:57 - MyApp] 'aapt' error. Pre Compiler Build aborted.
[2013-11-21 17:39:57 - MyApp] Starting full Package build.
[2013-11-21 17:39:57 - MyApp] Using default Build Tools revision 19.0.0
https://twitter.com/OnepieceVostfrf
https://twitter.com/dbs_vostfr
https://vk.com/@twflix24-one-piece-red-tw
https://vk.com/@cinemajos-avatar-la-voie-de-leau-streaming-vf-en-francais-vostfr-fr
https://issuetracker.google.com/issues/250610583
https://issuetracker.google.com/issues/250609756
https://issuetracker.google.com/issues/250609759
https://issuetracker.google.com/issues/250610272
https://issuetracker.google.com/issues/250610273
https://issuetracker.google.com/issues/250610276
https://issuetracker.google.com/issues/250610278
https://issuetracker.google.com/issues/250610593
https://issuetracker.google.com/issues/250610280
https://issuetracker.google.com/issues/250610923
https://issuetracker.google.com/issues/250610282
https://issuetracker.google.com/issues/250611106
https://issuetracker.google.com/issues/250610598
https://issuetracker.google.com/issues/250611463
https://issuetracker.google.com/issues/250611111
https://issuetracker.google.com/issues/250610933
https://issuetracker.google.com/issues/250610935
https://issuetracker.google.com/issues/250611113
https://issuetracker.google.com/issues/250610937
https://issuetracker.google.com/issues/250611116
https://issuetracker.google.com/issues/250611466
https://issuetracker.google.com/issues/250612724
https://issuetracker.google.com/issues/250612604
https://issuetracker.google.com/issues/250612726
https://issuetracker.google.com/issues/250611471
https://issuetracker.google.com/issues/250177858
https://issuetracker.google.com/issues/250172577
https://www.endezo-it.com/2022/10/the-dark-event-of-indonesian-football.html
https://www.49erssports.com/2022/10/kanjuruhan-tragedy-arema-fc-management.html
https://one-piece-red-full-movie-english.webflow.io/
https://documenter.getpostman.com/view/21828632/2s83tJGAat
Turned up build output to verbose and seeing something now.
Still not seeing anything _useful_ in the Console though...
Really I am just saying - aapt DOES CRASH on my very vanilla Win XP ADT setup. (As in Windows XP pops a dialogue and tries to send an Error Report to Microsoft).
I can reproduce it if anyone wants me to try anything further.
With verbose build output, below is the last bit of what I see:
Notice the fragmented output line "(new"
Interestingly, it seems to process the implicated menu fine earlier, but blows later amidst unrelated .wav files...
<Lots before this, then: >
...
[2013-11-21 17:39:55 - MyApp] (new resource id say50 from C:\AndroidDev\EclipseWorkspace\MyApp\res\raw\say50.wav)
[2013-11-21 17:39:57 - MyApp] (new
[2013-11-21 17:39:57 - MyApp] 'aapt' error. Pre Compiler Build aborted.
[2013-11-21 17:39:57 - MyApp] Starting full Package build.
[2013-11-21 17:39:57 - MyApp] Using default Build Tools revision 19.0.0
Description
AI-181.5540.7.32.5056338, JRE 1.8.0_152-release-1136-b06x64 JetBrains s.r.o, OS Windows 10(amd64) v10.0 , screens 1718x928
Android Gradle Plugin: 3.2.1
Gradle: 4.6
NDK: from local.properties: 19.0.5232133; latest from SDK: 19.0.5232133;
LLDB: pinned revision 3.1 not found; latest from SDK: (package not found);
CMake: from local.properties: (not specified); latest from SDK: 3.10.2; from PATH: (not found);
Issues:
Android Studio no longer recognizes standard system and JNI headers from the NDK in C++ files.
Android Studio can no longer generate new JNI functions for native java functions.
Steps to reproduce:
1. Install Android Studio 3.2.1 (the latest version 3.3 is too broken to use. See issue: 123071299, as well as 3.4 beta1 - See issue: 123071300)
2. Use all default locations and proposed items to install
3. Create a new Mobile project with C++ support. See attached images Step1-6
4. Install NDK as proposed by Gradle
5. Install CMake as proposed by Gradle
After all the Gradle Syncs and indexing you should be looking at a situation as displayed in Capture1 (Sorry about the Snipping Tool overlap).
Two major issues become apparent immediately:
1. The broken interlink between the wizard generated "stringFromJNI <-> Java_com_example_alesom_testapp_MainActivity_stringFromJNI" can already be observed (no red/green arrows on the left side of the window that allow a jump from Java to Native code and vice versa).
2. Native code is all red from "syntax errors" and neither jni.h and string include files are recognized
To make sure that the initial lack of NDK and CMake didn't spoil the broth, I repeated the same procedure a second time with NDK and CMake installed.
Steps to reproduce:
1. Create a new Mobile project with C++ support. See attached images Step1-6
After all the Gradle Syncs and indexing you should be looking at a situation as displayed in Capture2.
Again both issues appear:
1. The interlink between the wizard generated "stringFromJNI <-> Java_com_example_testapp_MainActivity_stringFromJNI" is half broken with the red/green arrows on the left side of the window only in Java but not in Native code.
2. Native code is all red from "syntax errors" and neither jni.h and string include files are recognized
3. It is not possible to get rid of the Failed Gradle Sync status on top of Java and C++ windows. The sync appears to be successful and it IS possible to build and run the application.
To resolve the Sync issue the following was attempted:
1. Build -> "Refresh Linked C++ Projects"
2. File -> "Sync Project with Gradle Files"
3. Android Studio restart
After step 3 the Failed Gradle Sync notification as gone.
Further issues:
1. The wizard for creating JNI functions from Java native method definitions is no longer working.
Steps to reproduce:
1. Define a sample function in Java code: public native String test();
2. Place the text cursor on the function name test() displayed in red and press Alt-Enter for the context menu to appear
3. Choose Create function .....
This will generate a partial code snippet in the middle of the definition of the previous JNI function.
Prodecure and result in snapshots:
JNI_native_create-function.PNG
JNI_native_generated-function.PNG
This makes the development process for developer leaning on JNI at a total loss.
Attached:
- log.zip (all the Android studio log files)
- Capture1.png (state of Android Studio after the first sample TestApp project was created)
- Capture1.png (state of Android Studio after the second sample TestApp project was created)
- Step1.png .. Step6.png (steps taken to create sample app)
- JNI_native_create-function.PNG
- JNI_native_generated-function.PNG
- TestApp1.zip (Test app as generated after fresh install)
- TestApp2.zip (Test app as generated after NDK and CMake were already installed)