Can any of the devs here compile an android version?
https://wiki.mozilla.org/Mobile/Build/Fennec
I believe everything you need to compile it should be there. If I knew how to do this I would but I'm just starting to learn how to code.
*edit: attached source
Thanks
-Mr. Biggz
The code required to make a proper working Sprint Hero build doesn't exist to the public.
In terms of what? I thought source code was platform independent.
Without knowing anything about fennec it looks like it can currently be compiled for windows mobile or for phones that can install debian packages. While android is linux the applications on our phone are java based.
So while those instructions are for compiling it for linux but that wouldn't actually run on our phone. And source code isn't platform independent, there are hundreds of different languages. For example my kitchen is written in VB. You can't take the source code (which relies on win API) and compile it for another platform.
Mr. Biggz said:
In terms of what? I thought source code was platform independent.
Click to expand...
Click to collapse
Um kinda but not really. C for windows is much like C for linux but there are differences, you can usually port code from one to the other by just doing a primary build then hunting down the errors.
When it comes to cell phones much of the code is platform specific, the Android core kernel is based on linux but requires application specific tweaks per devise which is why we can't just pop 1.6, 2.0, or 2.1 on the HeroC, we don't know how HTC made a GSM only rom work on CDMA because they are hiding what they did to make it work.
Android Games WILL be improved thanks to NDK r3 and OpenGL ES 2.0
Developers on the Android platform have already been pushing the boundaries of Android gaming. Even Quake 3 has been seen running on the Android platform. Things can only get better with today’s announcement.
The Android Developers Blog today announced the availability of the NDK r3 that will let android developers directly access OpenGL ES 2.0 features.
Applications targeting Android 2.0 (API level 5) or higher can now directly access OpenGL ES 2.0 features. This brings the ability to control graphics rendering through vertex and fragment shader programs, using the GLSL shading language.
A new trivial sample, named “hello-gl2″, demonstrates how to render a simple triangle using both shader types.
With access to these enhanced OpenGL ES features game graphics should be greatly improved and we should start to see an awesome future for Android gaming. Obviously, we still need developers to take advantage of the new API and have the hardware powerful enough to use it, but everything is getting real close to serious gaming on Android.
Source: Android Developers Blog
Source: AndroidSPIN
-----
What is the Android NDK?
The Android NDK is a toolset that lets you embed components that make use of native code in your Android applications.
Android applications run in the Dalvik virtual machine. The NDK allows you to implement parts of your applications using native-code languages such as C and C++. This can provide benefits to certain classes of applications, in the form of reuse of existing code and in some cases increased speed.
The NDK provides:
* A set of tools and build files used to generate native code libraries from C and C++ sources
* A way to embed the corresponding native libraries into application package files (.apks) that can be deployed on Android devices
* A set of native system headers and libraries that will be supported in all future versions of the Android platform, starting from Android 1.5
* Documentation, samples, and tutorials
This release of the NDK supports the ARMv5TE machine instruction set and provides stable headers for libc (the C library), libm (the Math library), OpenGL ES (3D graphics library), the JNI interface, and other libraries, as listed in the section below.
The NDK will not benefit most applications. As a developer, you will need to balance its benefits against its drawbacks; notably, using native code does not result in an automatic performance increase, but does always increase application complexity. Typical good candidates for the NDK are self-contained, CPU-intensive operations that don't allocate much memory, such as signal processing, physics simulation, and so on. Simply re-coding a method to run in C usually does not result in a large performance increase. The NDK can, however, can be an effective way to reuse a large corpus of existing C/C++ code.
Please note that the NDK does not enable you to develop native-only applications. Android's primary runtime remains the Dalvik virtual machine.
Contents of the NDK
Development tools
The NDK includes a set of cross-toolchains (compilers, linkers, etc..) that can generate native ARM binaries on Linux, OS X, and Windows (with Cygwin) platforms.
It provides a set of system headers for stable native APIs that are guaranteed to be supported in all later releases of the platform:
* libc (C library) headers
* libm (math library) headers
* JNI interface headers
* libz (Zlib compression) headers
* liblog (Android logging) header
* OpenGL ES 1.1 and OpenGL ES 2.0 (3D graphics libraries) headers
* A Minimal set of headers for C++ support
The NDK also provides a build system that lets you work efficiently with your sources, without having to handle the toolchain/platform/CPU/ABI details. You create very short build files to describe which sources to compile and which Android application will use them — the build system compiles the sources and places the shared libraries directly in your application project.
Important: With the exception of the libraries listed above, native system libraries in the Android platform are not stable and may change in future platform versions. Your applications should only make use of the stable native system libraries provided in this NDK.
Documentation
The NDK package includes a set of documentation that describes the capabilities of the NDK and how to use it to create shared libraries for your Android applications. In this release, the documentation is provided only in the downloadable NDK package. You can find the documentation in the <ndk>/docs/ directory. Included are these files:
* INSTALL.TXT — describes how to install the NDK and configure it for your host system
* OVERVIEW.TXT — provides an overview of the NDK capabilities and usage
* ANDROID-MK.TXT — describes the use of the Android.mk file, which defines the native sources you want to compile
* APPLICATION-MK.TXT — describes the use of the Application.mk file, which describes the native sources required by your Android application
* HOWTO.TXT — information about common tasks associated with NDK development.
* SYSTEM-ISSUES.TXT — known issues in the Android system images that you should be aware of, if you are developing using the NDK.
* STABLE-APIS.TXT — a complete list of the stable APIs exposed by headers in the NDK.
* CPU-ARCH-ABIS.TXT — a description of supported CPU architectures and how to target them.
* CHANGES.TXT — a complete list of changes to the NDK across all releases.
Additionally, the package includes detailed information about the "bionic" C library provided with the Android platform that you should be aware of, if you are developing using the NDK. You can find the documentation in the <ndk>/docs/system/libc/ directory:
* OVERVIEW.TXT — provides an overview of the "bionic" C library and the features it offers.
Sample applications
The NDK includes sample Android applications that illustrate how to use native code in your Android applications. For more information, see Using the Sample Applications.
Click to expand...
Click to collapse
You can download the Android NDK: here
just waiting for it ! Good job!
Kind of makes sense now why the binary 3D driver broke from 1.6->2.0
and i most care about whether our G1 are supported ?!
huhaifan1 said:
and i most care about whether our G1 are supported ?!
Click to expand...
Click to collapse
well if the rumors about every single android device being upgraded to 2.1 in the US are true then id think so. we already have partial 3D working, so i think with this release the devs will be able to make it work
Except the chip in the G1 is not built for 2.0.
IMHO, if you'll see 2.0 drivers on the G1 (or Hero) it'll be software. But I'd love to be proven wrong, so please do.
Chainfire said:
Except the chip in the G1 is not built for 2.0.
IMHO, if you'll see 2.0 drivers on the G1 (or Hero) it'll be software. But I'd love to be proven wrong, so please do.
Click to expand...
Click to collapse
from what ive read on androidspin and phandroid, some phones will receive a slimmer 2.1 that doesnt support lwp OTA. some devs have found ways to use software libs and kernel edits to use partial 3D acceleration in some 2.1 roms. Firerat and Case_ managed to get 3D and Youtube HD working on Canon's Roms. The next OpenEclair should have fully working 3D, lwps, and video according to wesgarner, so i think that this upcoming release mentioned in the article will provide more tools for our devs to use on the G1.
but when EXACTLY - like DATE - are they coming!?
chim4ira312 said:
but when EXACTLY - like DATE - are they coming!?
Click to expand...
Click to collapse
The NDK is available now, maybe the devs should look into it:
http://developer.android.com/intl/de/sdk/ndk/index.html
What is the Android NDK?
The Android NDK is a toolset that lets you embed components that make use of native code in your Android applications.
Android applications run in the Dalvik virtual machine. The NDK allows you to implement parts of your applications using native-code languages such as C and C++. This can provide benefits to certain classes of applications, in the form of reuse of existing code and in some cases increased speed.
The NDK provides:
* A set of tools and build files used to generate native code libraries from C and C++ sources
* A way to embed the corresponding native libraries into application package files (.apks) that can be deployed on Android devices
* A set of native system headers and libraries that will be supported in all future versions of the Android platform, starting from Android 1.5
* Documentation, samples, and tutorials
This release of the NDK supports the ARMv5TE machine instruction set and provides stable headers for libc (the C library), libm (the Math library), OpenGL ES (3D graphics library), the JNI interface, and other libraries, as listed in the section below.
The NDK will not benefit most applications. As a developer, you will need to balance its benefits against its drawbacks; notably, using native code does not result in an automatic performance increase, but does always increase application complexity. Typical good candidates for the NDK are self-contained, CPU-intensive operations that don't allocate much memory, such as signal processing, physics simulation, and so on. Simply re-coding a method to run in C usually does not result in a large performance increase. The NDK can, however, can be an effective way to reuse a large corpus of existing C/C++ code.
Please note that the NDK does not enable you to develop native-only applications. Android's primary runtime remains the Dalvik virtual machine.
Contents of the NDK
Development tools
The NDK includes a set of cross-toolchains (compilers, linkers, etc..) that can generate native ARM binaries on Linux, OS X, and Windows (with Cygwin) platforms.
It provides a set of system headers for stable native APIs that are guaranteed to be supported in all later releases of the platform:
* libc (C library) headers
* libm (math library) headers
* JNI interface headers
* libz (Zlib compression) headers
* liblog (Android logging) header
* OpenGL ES 1.1 and OpenGL ES 2.0 (3D graphics libraries) headers
* A Minimal set of headers for C++ support
The NDK also provides a build system that lets you work efficiently with your sources, without having to handle the toolchain/platform/CPU/ABI details. You create very short build files to describe which sources to compile and which Android application will use them — the build system compiles the sources and places the shared libraries directly in your application project.
Important: With the exception of the libraries listed above, native system libraries in the Android platform are not stable and may change in future platform versions. Your applications should only make use of the stable native system libraries provided in this NDK.
Documentation
The NDK package includes a set of documentation that describes the capabilities of the NDK and how to use it to create shared libraries for your Android applications. In this release, the documentation is provided only in the downloadable NDK package. You can find the documentation in the <ndk>/docs/ directory. Included are these files:
* INSTALL.TXT — describes how to install the NDK and configure it for your host system
* OVERVIEW.TXT — provides an overview of the NDK capabilities and usage
* ANDROID-MK.TXT — describes the use of the Android.mk file, which defines the native sources you want to compile
* APPLICATION-MK.TXT — describes the use of the Application.mk file, which describes the native sources required by your Android application
* HOWTO.TXT — information about common tasks associated with NDK development.
* SYSTEM-ISSUES.TXT — known issues in the Android system images that you should be aware of, if you are developing using the NDK.
* STABLE-APIS.TXT — a complete list of the stable APIs exposed by headers in the NDK.
* CPU-ARCH-ABIS.TXT — a description of supported CPU architectures and how to target them.
* CHANGES.TXT — a complete list of changes to the NDK across all releases.
Additionally, the package includes detailed information about the "bionic" C library provided with the Android platform that you should be aware of, if you are developing using the NDK. You can find the documentation in the <ndk>/docs/system/libc/ directory:
* OVERVIEW.TXT — provides an overview of the "bionic" C library and the features it offers.
Sample applications
The NDK includes sample Android applications that illustrate how to use native code in your Android applications. For more information, see Using the Sample Applications.
Click to expand...
Click to collapse
This doesn't at all in any way say that we're getting 2.0 drivers for the G1. All it's saying is that phones with 2.0 will be able to directly access ES2.0 functions.
Which, really, has absolutely nothing to do with the driver issue we face. Unless you can point out something I missed.
Gary13579 said:
This doesn't at all in any way say that we're getting 2.0 drivers for the G1. All it's saying is that phones with 2.0 will be able to directly access ES2.0 functions.
Which, really, has absolutely nothing to do with the driver issue we face. Unless you can point out something I missed.
Click to expand...
Click to collapse
sorry i probably misunderstood the article =/
im still not very experienced with android development, i thought this would help the devs a little bit with getting 3d working (since theyre already doing that without official drivers)
I did indeed get a humongous boner on reading this earlier. It was enhanced by 3D.
My favorite part about this is the new ability to use openGL in apps! That means the entire face of our OS is going to change.
...and speaking of OS... Qualcom/htc just released a new radio for the G1. The G1 To this day holds over 50% of the android installed user base. There is no doubt the G1 will live beyond 1.X
bleah writing games in opengl es 1.0 was hard enough...
Gary13579 said:
This doesn't at all in any way say that we're getting 2.0 drivers for the G1. All it's saying is that phones with 2.0 will be able to directly access ES2.0 functions.
Which, really, has absolutely nothing to do with the driver issue we face. Unless you can point out something I missed.
Click to expand...
Click to collapse
agreed
the binary still needs to be available
as far as I can see with have two
the open source one
/system/lib/egl/libGLES_android.so
and the proprietary
/system/lib/egl/libGLES_qcom.so
the quoted text in the OP is basically stating that an Android developer will now be able to mix in a little c/c++ to get direct native access to opengl es
functions
Firerat said:
agreed
the binary still needs to be available
as far as I can see with have two
the open source one
/system/lib/egl/libGLES_android.so
and the proprietary
/system/lib/egl/libGLES_qcom.so
the quoted text in the OP is basically stating that an Android developer will now be able to mix in a little c/c++ to get direct native access to opengl es
functions
Click to expand...
Click to collapse
sorry guys like i said i misunderstood =/ i was hoping the NDK would provide some help but i now see its pretty much for apps, facepalm >_<;
edited the title to avoid further confusion lol
speedysilwady said:
edited the title to avoid further confusion lol
Click to expand...
Click to collapse
Was just about to do that, thanks .
I'm sure we'll get drivers eventually, either hacked or official. Just a matter of time.
Gary13579 said:
Was just about to do that, thanks .
I'm sure we'll get drivers eventually, either hacked or official. Just a matter of time.
Click to expand...
Click to collapse
haha no problem, glad to see i have a moderator type mentality. lol
yeah im sure we will, theyre already partially working, so its only a matter of time hopefully
What Chainfire said is that there is no hardware support for OpenGl ES 2.0 in msm720x chips. (refs here, sorry couldn't find official spec datasheet).
So even if 2.0 is supported, it will only be through software drivers implementation, which means really slow rendering.
spocky12 said:
What Chainfire said is that there is no hardware support for OpenGl ES 2.0 in msm720x chips. (refs here, sorry couldn't find official spec datasheet).
So even if 2.0 is supported, it will only be through software drivers implementation, which means really slow rendering.
Click to expand...
Click to collapse
Thats right.
But most Games will probably/hopefully still be written for OpenGL1.1. (Because of the userbase whatsoever)
For a start, but to focus at the future, too bad, the G1 will get old sooner
So this is probably a silly question.
I have this rather complicated app that would be a heck of a lot of work to convert to Java.
It runs in the command line and works fine in Linux.
Trying to run it fails, but x86 bytecode probably isn't very ARM friendly.
Is there a specific way I need to compile the application?
Is it even possible to run it from a console emulator?
Thanks.
Try Android NDK
I am also new to Android Dev ( 15+ years Linux, 10+ years Java, etc.)
I am not an expert but for your purposes you need the "Android NDK" in addition to the "Android SDK" that most developers utilize.
"The Android NDK is a toolset that lets you embed components that make use of native code in your Android applications.
Android applications run in the Dalvik virtual machine. The NDK allows you to implement parts of your applications using native-code languages such as C and C++. "
Basically the tools are needed to cross compile C++ source code for the target ARM environment.
I am prevented from posting the download URL for some bizarre reason, but it is listed under "Native Development Tools" on the left side of the web page for the standard "Android SDK" download.
Yeah that's because you are new. It's a system to prevent spammers from posting URLs.
When you have a couple of posts the restriction will disappear
Anyway; found it, seems to be what I'm looking for.
I'll check it out in the morning.
Big thanks
Dmitry Moskalchukhas written a patch for the ndk to better support c++ see crytax dot net there are posts on google groups android-ndk talking about it
Thxs for the info. I was aware that the NDK did not include all of the libs that desktop Linux/UNIX developers expect. The suggested patched version adds the STL libs back in.
Sent from my PC36100 using XDA App
There are A LOT of libraries missing
I guess I'll just keep it a hosted app.
Thanks for all the input
I tried to post this in the development forum, but I am not allowed.
I am tinkering with ARM architecture and Android device development and low level OS stuff. I am currently using QT C++ for Android for app development. This works great for all of my standard Android app development, but now I am digging deeper. I am doing an experiment where I have a small binary blob (64k) of ARM code that I want to load into memory at run time using mmap(). In order for this code to work, it needs to be loaded at address 0x22000000. In my C++ code i call mmap(0x22000000, ...) which would map the binary file to that address only if it were not in use already, which it is on a couple different android devices that I have tried, so it maps to another address, as it should by design. I tried using MAP_FIXED as a flag to mmap() and the application crashes, as expected, since mmap() overwrites memory that is already in use.
In order for mmap() to map the binary file to the address I want, I believe that I can do some sort of advanced Android / Kotlin / gradle level compile time linking modifications in order to make sure that the area of memory (the whole page at least I imagine) that I want to mmap() to is unused when execution reaches my C++ code that calls mmap(). I don't know the android build system very well though, so I hope some Android experts can help me. I am not trying to access real physical RAM though, only address 0x22000000 in the processes virtual address space. Because of this, I believe that with some custom hackery can be done during linking to modify the areas of RAM that are assigned for program/stack/etc use. I believe I am looking for the equivalent of LD script customization for standard GCC C/C++ compiled software, and possibly some direction on how to manipulate.
I have successfully done this on a raspberry pi running raspbian via a command line C++ application, as well as an x86_64 Fedora system using an x86_64 binary blob. In both cases I got lucky that the area of memory was not in use, so mmap() succeeded and I was able to execute the code as desired.