Q:

Does Android NDK inherit Java problems?

I want to create a game for Android and I need to choose between SDK and NDK. Mobile phones have limited hardware and I want to avoid slowdown, but Java is slow and uses too much memory.
Are NDK apps faster and more efficient than SDK apps?
Java uses a garbage collector, all objects are allocated on heap, I cannot allocate an object inside another object (without a pointer), and a simple class that is used as a struct inherits the Object class.
Will my NDK program be converted into Java bytecode? Will the compiler ignore my delete calls, add garbage collector, add the Object class and transfer all of my objects to heap?

A:

I'll attempt to clear up some things:

On Android, you always develop using the SDK. You can think of the NDK as a addon to the SDK. What the NDK does is allow you to develop native (e.g. C/C++) code in companion to your Java code (what you do on each side is up to you)
Are NDK apps faster? Again, it depends on what you're doing. Java can do a lot of things fast on devices with JIT especially. Well written C/C++ code is generally faster, yes. However, you also have to pay a penalty for going to and from Java/native (via JNI)
If you look, there are game engines for Android written in the NDK. As of NDK r5 (and of course newer Android versions) you have the ability to draw to the screen from the NDK without first passing through Java/JNI which can give huge performance gains.
No, your native code will absolutely not be converted to bytecode. It will be compiled as native ARM/MIPS/x86/whatever machine code.
Unless you implement your own GC in native code, new, delete, etc. behave as normal. The Java VM doesn't know anything about your native allocations unless you explicitly call JNI methods for creating new objects.

A:

It sounds like your understanding of NDK vs SDK is a bit unclear.
When you develop apps with the SDK, you are writing in Java. When you are develop apps for the NDK, you are writing in C/C++.  I think a lot of people are going to argue that C/C++ is faster for games (among other things), but I believe if you want your development process to be easier, you might want to use the SDK; at least if you have a simple 2D game and don't need to implement a graphics engine with shaders, that is.
Your third paragraph is full of a lot of bad assumptions and wrong connotations. As if having a garbage collector is bad, all implementations of a heap are bad, basic Object-Oriented design structure of inheriting an Object class are bad. And yeah you can have objects inside objects.
And no, it won't be converted to bytecode. No, the compiler won't ignore delete, add the Object class (how/why/what?), or anything else.

