IssueTracker

I've raised a similar issue: http://code.google.com/p/android/issues/detail?id=40153

Why does/can it not pick up the previously set Eclipse name if present, as per the non-Android import of a project? This is what I expect to happen; indeed it is what used to happen, and still does for libraries. In particular under certain working configurations, e.g. source control branches, it is necessary to have a naming differentiator.

At the very least the manifest may have an application name/label, which would be better than the activity name.

If you are importing an Eclipse project (which has a .classpath), just use the generic Eclipse project import mechanism; that's still there (Import > General > Existing Projects Into Workspace).

We added Import > Android > Existing Android Code Into Workspace because a lot of people had non-Eclipse projects to import, which was not well supported; you had to "Create New" and then use a checkbox to select "existing code" etc, and the location of the project and the location of the existing sources was ambiguous.

We made the Existing Android Code import option *also* work for Eclipse projects, such that it would be a single obvious way to pull in source code. But this is new code, not the general Eclipse builtin import code, which is why it doesn't pick up the project name in the way it used to. (The related code which handled adding new project from source did act in the same quirky way the code does now, picking a project name from the manifest).

However, making it look up the project name from the .project file as a better default, if present, should be doable so I'll try to add that as well.

Ah, thanks for the explanation. I hadn't realised that the generic Eclipse import was appropriate for Android projects, but on testing it I see that it resolves the problems in my linked issue.

Note that said issue is not wholly redundant; it also reports that the Android-specific import process changes the compatibility level, which I expect is for similar reasons. The Eclipse import does not do this, so I personally no longer have a problem; I just didn't expect different behaviours.

I tweaked the wizard a bit such that there's an edit column and the default names should pick up old Eclipse names: https://android-review.googlesource.com/46770

I have compiled the new ADT and have some feedback. My "Project to Import" column has the names I would like to set on my projects; the New Project Name column shows NativeActivity for all my projects (they are all NativeActivities).

I started to change the names one by one and noticed that the "New Project Name" column is not clickable. I can't do like in a spreadsheet, change the name of a project and press Enter to move to the next row. Would it be possible to fix this. Is there a faster way to copy the "Project to Import" column to "New Project Name". And finally, if there is a jni folder in the project, it would be awesome to add C/C++ nature to the project during the import process.

Thanks!

Thank you for submitting this issue. It was last modified before Android Studio 1.0 Launched in 2014. We have made a large number of improvements in Android Studio since 2014 and hope this issue is already resolved. In order to correctly prioritize issues in our upcoming release, we are closing this bug. If you continue to experience your issue on the latest stable version of Android Studio, please submit a new bug report. We apologize for any inconvenience this may cause you.

Hi,

I've sent the patch for a review to gcc-patches mail list. You are in cc.

I removed stdio.h and compiler.h fixes for Android (stdio.h is the most harmful one).


Here are the fixes that are left for Android:

linux/a.out.h (the fix is called "machine_name"). It fixes non-ansi machine defines - "linux" define is one of it, so it changes the define to "__linux__"

I'm not sure about the implications of removing this fix for Android. BUT, a.out.h from android-9 and android-L are different (!). So it potentially could be harmful.
We need to decided what to do here.


syslimits.h, limits.h (they are the same fix). The "fixed" limits.h includes the actual limits.h and adds up a bunch of gcc-defined macros. Don't see that as a potential problem.


posix_types.h (the fix AAB_fd_zero_asm_posix_types_h). "fixed" header includes the real one and rewrite __FD_ZERO implementation. Also don't see any problems here, so I decided to left it untouched.


 

Thanks to the fixes stdio.h and compiler.h are now removed:

https://android-review.googlesource.com/#/c/103445 # stdio.h
https://android-review.googlesource.com/#/c/104060 # compiler.h

We need to remove linux/a.out.h as well.  Although all android toolchain defines both linux and __linux__ and makes the GCC fix from linux to __linux__ irrelevant, the old a.out.h does "#include <asm/page.h>" no longer exists in android-L, and the new a.out.h in android-L "#define SEGMENT_SIZE getpagesize()" refers to getpagesize() not avaiable in older platform's libc.so (where getpagesize is a static inline function).  32-bit GCC compilers built from android-9 may fail to compile "#include <linux/a.out.h>" when sysroot is set to android-L's header.

The NDK package script can remove it for now.  Please suggest better fix in GCC

Ok, I'll take a look. At first glance, seems that a.out.h in kernel has to be changed, cause gcc claims that "linux" is non-ansi machine define (Have no idea why is that so).

Anyways, this "fix" is no doing anything useful, since even on linux we have:

gcc /nfs/ims/home/aivchenk/hello.c -E -dM  | grep linux
#define __linux 1
#define __linux__ 1
#define __gnu_linux__ 1
#define linux


As for stdio.h.. development headers still needs to be updated..

include-fixed/stdio.h is gone in r10b recently released.

It looks like stdio.h is gone from too many places. Including sysroot/usr/include of standalone toolchains

In standalone toolchain sysroot/usr/include is copied from one of $NDK/platforms/android-N/arch-X of your choosing.  I have double checked stdio.h is still presence in all level/arch.  Could you run the following commands ?

~/android-ndk-r10b$ ./build/tools/make-standalone-toolchain.sh --arch=arm --install-dir=/tmp/ndk-$USER/aa

Auto-config: --toolchain=arm-linux-androideabi-4.6
Copying prebuilt binaries...
Copying sysroot headers and libraries...
Copying c++ runtime headers and libraries...
Copying files to: /tmp/ndk-$USER/aa
Cleaning up...
Done.

~/android-ndk-r10b$ find /tmp/ndk-$USER/aa -name stdio.h
/tmp/ndk-$USER/aa/include/c++/4.6/tr1/stdio.h
/tmp/ndk-$USER/aa/sysroot/usr/include/stdio.h

This issue can probably be closed since it has been fixed.

a.out.h is still not removed yet (it's removed at package)

although a.out.h is still a problem, it's unlikely to affect anyone in 2015.

I've sent a trivial fix for a.out.h to kernel some time ago: https://lkml.org/lkml/2015/3/10/286
will ping again

thanks!