My favorites | Sign in
Project Home Issues
New issue   Search
  Advanced search   Search tips   Subscriptions
Issue 33788: [ADT 20] Indexer support regression
82 people starred this issue and may be notified of changes. Back to list
Status:  FutureRelease
Closed:  Sep 2012

Sign in to add a comment
Reported by, Jun 27, 2012
Host OS: Windows 7 x64
SDK tools version: 20
Eclipse version: Version: Juno Release (4.2) Build id: 20120614-1722
ADT plug-in version: 20.0.0.v201206242043-391819
Platform targeted by your project: nvm
Version of the platform running in the emulator: nvm

1. Add native support to project (it creates .cpp with inclusion of jni.h)
3. In project properties: C++ General - Paths and Symbols
4. In includes tab add <ndk-path>/platforms/android-9/arch-x86/usr/include
5. Apply and rebuild index

Resolved inclusion (of jni.h or whatever)

Unresolved inclusion

Inside Include tab of Paths and Symbols in project settings there is only c,cpp language - which does not suit indexer I guess.
There is also red sign inside Preprocessor Include Paths, Macors etc properties branch saying "Cannot determine toolchain languages."

Jun 27, 2012
Project Member #1
(No comment was entered for this change.)
Jun 28, 2012
Project Member #2
So it looks like CDT 8.1 released a couple of days ago doesn't support the old style discovery of paths. While we fix that, here is the workaround:

1. Manually install CDT 8.0.2 or earlier.
2. Install ADT after installing CDT.
3. Replace the NDK plugin that is installed with ADT 20 with the attached version. (Look for in the folder eclipse/plugins, delete it and use attached)

This should enable indexing to work fine on Windows, but only with pre 8.1 versions of CDT.
Jun 30, 2012
Did you forget the attachment?
Jun 30, 2012
Project Member #4
Ugh, sorry about that. Let me see if it comes through this time.
90.3 KB   Download
Jun 30, 2012
To workaround I change toolchain in C++ Build to cygwin or whatever, which enables C/C++ language inside Paths and Symbols
Jun 30, 2012
The replacement plugin doesn't load with a fresh install of either Eclipse 3.8 or 4.2 with CDT 8.0.2. I don't see any errors in the console, but after replacing the jar file and restarting Eclipse, the "ADT CDT Integration" feature is no longer listed in the installation details and there is no apparent NDK integration functionality.

Following P.Lesie...'s tip, I temporarily changed the toolchain to cygwin, added the NDK paths, hit Apply then switched the toolchain back to Android GCC. This seems to work.

Jul 16, 2012
The switch toolchain solution dit not work for me when switching back to the Android GCC. Instead, I changed it to cygwin and set 'Current Builder' as Android Builder. Without changing plugin version or whatever. Added the path to ANDROID_NDK/platforms/android-9/arch-arm/usr/include and it's working. At least for now, as I'm still learning.
Jul 18, 2012
Project Member #8
We have 20.0.1 released which should fix this issue as long as you are using CDT 8.0.2 or earlier.

You shouldn't have to manually add include paths to platform directories.
Jul 26, 2012
Using NDK plugin (20.0.2.v201207191942-407447) on Eclipse Version: 4.2.0
Build id: I20120608-1400 with CDT on Windows 7/64 still gives "Unresolve inclusion: <jni.h>.  Happens both when adding the ndk/platform... path or without it.
Jul 26, 2012
Project Member #10
Yup, as mentioned in comment #8, you have to use CDT 8.0.2 or earlier. CDT 8.1.0 changes how indexing works and doesn't seem to be backwards compatible.
Jul 26, 2012
That's the original bug. It doesn't work with CDT 8.1. See mine & P.Lesie's comments above for a work-around. Once you "fool" it into picking up the directories by temporarily switching the toolchains, it works well.

Jul 26, 2012
Project Member #12
Ok, please correct me if my understanding is incorrect:

CDT 8.0.2 or earlier: no workarounds needed as long as you are using 20.0.1 of ADT.
CDT 8.1.0: workaround as specified in comment #5 should get things to work.
Jul 26, 2012
For 8.1 yes. I have not tried the 20.0.2 update yet and I don't want to downgrade my CDT, so the work-around in #5 & #6 works best for me.
Aug 20, 2012
Project Member #14
Another workaround for people using 8.1.0: First do: "Window -> Preferences -> C/C++ -> Property Pages Settings" and deselect the option "Display 'Preprocessor Include Paths' and enable language settings providers'. Then add the NDK nature. Then it automatically resolves the include path locations.
Aug 21, 2012
I'm using CDT 8.1.0 and ADT 20.0.3. I tried work-around #5 and it seems to work fine, however #6 doesn't work at all. I also wanted to try #14 but I don't understand what 'Then add the NDK nature.' sentence exactly means.
Aug 21, 2012
Project Member #16
Sorry, what I meant to say was that you need to apply the property page settings, and then create a new Android project and do a right click project -> "Android Tools -> Add Native support". The setting didn't seem to affect already existing projects, but only newly created ones.
Aug 21, 2012
Project Member #17
Fixed with
Should be part of ADT 21, starting from preview 2.
Status: FutureRelease
Aug 22, 2012
Project Member #18
ADT 21 Preview 2 is now up here:
Feel free to update this thread if there are any issues.
Aug 24, 2012
#19 b95505017
I installed ADT 21 Preview 2, then import NDK-sample/Plasma
It can't resolve AndroidBitmapInfo, ANDROID_LOG_INFO...etc. in the log.h & bitmap.h, are these my setting problems or bugs?

螢幕快照 2012-08-24 下午5.44.36.png
230 KB   View   Download
Aug 24, 2012
Project Member #20
So when you say "then import NDK-sample/Plasma", do you mean that you imported that project, then added ndk nature to it, or did it already have the NDK nature from previous ADT 20?

To clarify, these steps are needed in ADT 21preview2:

1. Right click project, Android Tools -> Add Native support. If this menu item is not visible, then the project already have old style CDT support, and will not work. You can try removing the .cproject, but I haven't tested if that works.

2. Once you add native support, explicitly do a build (Ctrl/Cmd + B).

After those 2 steps, indexing should work. If not, then it is a bug.

Also, I will be out next week, but will look at any issues the week after.
Aug 24, 2012
There's still a bug with files endings in .c. This project:

gives me an error in indexer1.c line 6:
Field 'f_blocks' could not be resolved

If I rename it to or .cpp, there are no errors.

The filename in doesn't seem to matter - is it safe to delete that file for ADT+native nature projects?
Aug 24, 2012
Project Member #22
No, when you do a build in Eclipse, it simply calls out to ndk-build, which uses the So that file should be there, and it should correctly build all of your files - the current NDK Eclipse plugin doesn't offer any help with Makefiles.
Aug 24, 2012
#23 b95505017
The samples in NDK don't have NDK nature, so after choosing importing from "Existing Android Code into Workspace", then "Add Native Support", but in my Eclipse Juno, function and struct called from "android/xxxx.h" can't be resolved, just like my picture above.
Aug 25, 2012
#25 b95505017
Oh, BTW, after I rename plasma.c to plasma.cpp, it work ok in my Juno!
While in Indigo, it work ok without having to rename it.
Aug 25, 2012
I'm also on Juno (.cpp/.cc indexed properly but .c broken).

About, I think a stale build tree was hiding the problem. Doing a full Clean/Build Project cycle, I can see that having the wrong filename in causes an error to show up in the Problems view.
Aug 25, 2012
Hm, seems .cc is not supported at all, ndk-build says:

Android NDK: WARNING: Unsupported source file extensions in jni/ for module <module>
Android NDK:   <filename>.cc    

Sep 5, 2012
Project Member #28
Sorry about the delay, I was Out of Office.

From what I see, it looks like the only issue now is what extensions are supported by the file. Is that correct? If that is the only issue, please file a separate bug report for it.
Sep 5, 2012
#29 krystian.lew
I can reproduce the bug with different file names - .c is broken (although i can browse for declarations, etc. but error markers are still there), while .cc is fine.
Sep 5, 2012
Exactly, supports .c and .cc, but indexing only happens correctly for .cc files.

.cpp are unsupported in both cases, and that's fine.
Sep 5, 2012
Project Member #31
(No comment was entered for this change.)
Status: Assigned
Sep 13, 2012
Project Member #32
I tried this today, and am not seeing any issues with Eclipse 3.8 + CDT 8.1.0.

Comments #29 and #30 mention that .cc is fine. But .cc happens to be the extension that is not supported by the NDK makefile. It supports .c and .cpp just fine.

As far as the error marker that shows up in the github project specified in Comment #21, that seems to be a CDT bug with Codan. You can go to CDT preferences and turn off "Code Analysis" and see that the marker disappears.

So I think it is important to differentiate indexer bug vs. some other bug. If the include files are resolved, i.e. double click in jni.h gets you to the correct header, then I'd imagine that the indexer is working fine. Since Comment#29 mentions that you can actually jump to header files, I think you are also seeing the Codan error.

Please update this thread if you get a chance to try this after turning off CDT's Codan.
Sep 14, 2012
Project Member #33
 Issue 37427  has been merged into this issue.
Sep 17, 2012
Project Member #34
(No comment was entered for this change.)
Status: FutureRelease
Oct 6, 2012
Hi for all.

JNI working with Eclipse Juno SR1, CDT 8.0.2 and ADT 20.0.3

I decided to do a little tutorial.

I tested this tutorial and it worked perfectly.

See the attached pdf for more information.

Best regards for all.

           Julio Lemos

I converted this document from a DOCX to PDF from this
tutorial eclipse juno sr1 working with android jni.pdf
2.9 MB   Download
Oct 30, 2012
Eclipse 4.2.0, CDT 8.1.0 and ADT 20.0.3. Workaround #14 works fine.
Nov 13, 2012
I tried comment #20 with latest preview version of ADT (21.0.0.v201210310015-519525 - 21 preview 10). Afterwards I've added <NDK-HOME>\platforms\android-9\arch-x86\usr\include\ and <NDK-HOME>\sources\cxx-stl\gnu-libstdc++\4.6\include\ to the include directories list at Project->Properties->Paths and Symbols->Includes.
Then the jni.h inclusion in the c file has been fixed. I also added a printf-statement there, this has been also recognized correctly as function name from the indexer, so the indexer seems to work for c files. 
However, in .cpp file I included string header. The inclusion itself is fine for the indexer, but where I try to use "string" it tells me "Type 'std::string' could not be resolved".
It doesn't matter if the C++ file has .cpp as file extension or .cc the result is the same - std::string is not recognized. In the same file I throw a std::runtime_error - this is also not recognized. So it seems to be a generic issue for .cc and .cpp files.

Nov 16, 2012
I've found out what was the problem there. It seems the indexer has problems if eclipse has been installed in a path containing spaces. As long as no spaces are in the path, the indexer will resolve automatically all dependencies - otherwise the include pathes need to be set manually. Furthermore in this case also preprocessor macros defined by the toolchain (like ANDROID or __ANDROID__) or user defined macros in the *.mk files are unknown to the indexer. I will create a separate bug report about this. Verified with Eclipse 3.8 and 4.2.1 and ADT 21.0.0 (official release).
Jan 27, 2013
Confirming that #32 was indeed correct for me: After disabling the "Method cannot be resolved" check in "Code Analysis" settings, errors about missing methods from jni.h are no longer shown and everything seems to work as expected.
Feb 2, 2013
#40 there is no error on the head file ,but it has trouble on the source file ,it can not find the namespace and so on. I try to find the bug on the CDT bug list ,but it's useless . It seems there is not a simple solution for this .
Mar 5, 2013
Eclipse Juno SR2, ADT 2.1, CDT 8.1.2, OS : MACOSX -> still not working !
Include paths are properly resolved (can click and open jni.h included file for example) .... 
BUT still many errors are displayed : Method, or Type '...' could not be resolved.
If I disable Code Analysis in CDT preferences of course errors do not appear anymore, BUT the problem is that objects are not resolved, so there is no completion in the editor, can't properly develop with that !
If renaming file to .cpp that kind of problem does not appear, but I cannot always work with .cpp files, I have to use also .c files.
Is there a newer release working for this ?? 
Mar 6, 2013
Linux 3.8.2, latest Eclipse Juno SR2 (4.2.2), latest ADT (21.1.0.v201302060044).

I'm getting a lot of unresolved inclusions: <jni.h>, <stdlib.h>, <string.h>, <stdio.h>, <android/log.h>, etc. 

No matter if I use .c or .cpp or .cc. Eclipse shows correct include paths: 


Please Google fix this. It's been more than 6 months now. Please.

Mar 22, 2013
Windows, Latest Eclipse Kepler Milestone 4.3M6, latest ADT (21.1.0.v201302060044), latest CDT (CDT 8.1.2). Still lots of unresolved inclusion errors Method, or Type '...' could not be resolved.... . Even though jump to definition thingy works perfectly, jumps to correct file and definition. librarys are also correctly displayed in workspace folders... compilation works without any problems.
but the "wrong" errors are very annoying. in a large project they fill out the error window. and it is makes it hard to see the real errors.
Mar 23, 2013
adt r21 is not compatibal with cdt 8.1.2
adt r21 with cdt 8.1.1 work fine.
Mar 27, 2013
OK, disregard previous comment. I did manage to get it to work, but you need to manually rebuild the index. So, if you really want this to work you will need to:

1. Clean install of Eclipse (some edition such as "Classic" without CDT)
2. Add CDT 8.1.1 from master zip (
3. Add ADT with NDK support
4. Configure SDK & NDK locations
5. Create test project, add native support
6. Note that you will initially see errors.
7. Run a build (the #include error markers will go away).
8. Right-click the project and select Index | Rebuild.

Now it should work.

Mar 28, 2013
Well, looks like I've spoken too soon again. After some combination of shutting down and relaunching Eclipse and/or closing/reopening the project, the errors come back and there appears to be no way to make them go away. At this point, it looks like comment #45 is incorrect -- NDK integration is completely broken with Juno regardless of which version of CDT you attempt to use.
Apr 26, 2013
Hope someone can fix this bug. 
Mac OS X Mountain Lion, ADT 21.1.0, CDT 8.1.2, Eclipse Platform 4.2.1.
May 10, 2013
Its actually pretty easy to fix ( work around ) this issue. Basically because of the incompatibility is is only resolving / indexing headers for cpp files.

What we want is to use the Android GCC toolchain but change the actual tools and modify the discovery options so that the include paths and symbols are correct.

Go into C/C++ Buid \ Tool Chain editor

Make sure Android GCC is the selected toolchain and Android Builder is the selected builder.

Click on "Select Tools"
Select "Allow all changes"
Remove the Android GCC Compiler
Add "GCC C Compiler" and "GCC C++ Compiler" so that we can index both c and cpp headers.

If you would look at "Paths and Symbols" you would see we have both GNU C and GNU C++ languages, but of course the built-in include paths are wrong. luckily there is a fix for that.

Go into C/C++ Build \ Discovery Options
Change Discovery profiles scope to "Configuration-wide"
Make sure the Discovery profile is using "AndroidPerProjectProfile" and make sure both checkboxes are checked.

The ndk include paths should now be correct including include paths defined in files.
May 15, 2013
Following comment #50, consistently causes my Eclipse to crash...
May 15, 2013
Most common eclipse crashes are memory related (OOM). Have you tried raising memory limits?

Those changes only affect the indexer so in case its not a memory related issue id suggest searching for CDT indexer issues.
May 19, 2013
#50 kills my Eclipse too. It goes into a busy loop immediately after removing Android GCC Compiler.
May 29, 2013
#50 is the only fix that works on ADT 22.0, Eclipse 4.2.1 and CDT 8.1.2
Jul 22, 2013
#57 morgwai
Problem still persists on eclipse-4.3 + cdt-8.2.0 + adt-22.0.4 :(
Jul 23, 2013
#58 morgwai
Actually on the above configuration the problem is triggered only when importing projects (from git or filesystem) into workspace. When creating a new project and adding native support to it, it works fine. So here is what I do to workaround the problem:

- create a new project with the same name as the one I want to import and add native support to it (indexing works ok and ndk includes are resolved properly)
- close the project (not delete!) and replace it content on the disk with the one I want to import
- reopen and rebuild the project
- sometimes also index rebuild is necessary

So far it works every time :)
Sep 12, 2013
Why is this issue marked closed?  I still have the issue on eclipse-4.3, cdt-8.2.0, adt-22.0.5

Unfortunately comment 58 did not solve it for me. :(
Sep 12, 2013
It doesn't look like NDK support in Eclipse is very important to Google. I wonder if they are planning something new with Android Studio.

Ultimately, I decided to just punt on NDK-Eclipse integration, and for that matter, most of the NDK as well. At the heart of it, it is just a pretty vanilla ARM gcc suite, so I just CDT with a makefile project that uses the toolchain directly rather than futzing with all of Google's hokey build scripts. This actually ends up being a cleaner and simpler solution if your project is pure native.

Nov 5, 2013
Still having this issue with eclipse-4.3, cdt-8.2.1, adt-22.3, None of the proposed workarounds help.
Nov 6, 2013
Having this issue with eclipse-4.3, cdt-8.2.1, adt-22.3. No workarounds help. 
Nov 14, 2013
#50 was crashing my eclipse until I tried highlighting "GCC C Compiler" on the left, "Android GCC Compiler" on the right, and clicking "<<- Replace ->>"

This on eclipse-4.2.1, cdt-8.1.2, adt-22.3
Dec 2, 2013
Change .c extension .cpp then the error is solved...Check my Screenshots...I think its useful...
Screenshot from 2013-12-02 20:44:59.png
286 KB   View   Download
Screenshot from 2013-12-02 20:45:48.png
281 KB   View   Download
Dec 2, 2013
^ Yes, that's a workaround, but it may require adding "extern 'C' " to your code, because it may now be treated as C++.
Dec 2, 2013
No its not needed..because the native support library created with .cpp extension by it automatically no need to adding c extern and all..! 
Apr 18, 2014
#67 beworker
Answer #50 was the solution/workaround for the issue. Thanks! I posted step-by-step instruction to
Apr 18, 2014
thanks for sharing.
I would recommend you also try mts to mov converter which is free to download trial software.

Sign in to add a comment

Powered by Google Project Hosting