native (C++) SDK for Android is definitively needed
sbVB
For many reasons, Android MUST have a C/C++ SDK.
For instance: I have countess lines of code written in C++ and
wxWidgets; of course, I want to compile this to Android. Don't tell me
Java is better.
I'm focusing in reusing my code.
I've spent many hours digging out the web, finding "hacker-like"
recipes to use native code on Android, as well as my own hours of
experimentation.
But that's not the way it should be.
For the sake of Android, the Google development team must provide a
complete C/C++ SDK for Android, much similar of the one found in
Linux.
Development tools such as g++, make, ldconfig, ar, etc. should be
included in this C/C++ SDK for Android.
If Google does not provide this C/C++ SDK, Android might get
discredited.
Stone Mirror
鏡石
Guilherme
Android is linux and the development using native language must be
encouraged.
On 9 mar, 22:08, "Stone Mirror" <stonemir...@gmail.com> wrote:
vladimir.sch...@gmail.com
Android diagram shows that most high level functions are Java (see
http://code.google.com/android/what-is-android.html blue boxes), those
are native when using Java. All Android application model is there.
C/C++ only seems to include graphics libraries, codecs, SQL, SSL, i.e.
not much.
Stone Mirror
Android is linux...
Not in any usual sense: it just uses a Linux kernel.
--
鏡石
hackbod
> 2008/3/9 Guilherme <guilherm...@gmail.com>:
> Not in any usual sense: it just uses a Linux kernel.
kernel, with a libc and most other standard Unix libraries as you'd
expect. True, it doesn't include X windows, or GTK, or KDE, but I
think it's a questionable position that those things are required to
call something "Linux."
Heck, the FSF even counts using glibc as meaning you need to call it
"GNU/Linux," so to at least one vocal group of people all you need is
the kernel to call it Linux. :)
Stone Mirror
On Mar 9, 6:45 pm, "Stone Mirror" <stonemir...@gmail.com> wrote:
> 2008/3/9 Guilherme <guilherm...@gmail.com>:
> > Android is linux...I guess it depends on what you define as usual -- it is a real Linux
> Not in any usual sense: it just uses a Linux kernel.
kernel, with a libc and most other standard Unix libraries as you'd
expect. True, it doesn't include X windows, or GTK, or KDE, but I
think it's a questionable position that those things are required to
call something "Linux."
It seems extremely unclear (if not misleading) to simply refer to Android as "a Linux system". I'm not sure if anyone from Google's been doing that with any regularity, but no one from there has been doing anything to correct people's misapprehensions.
There's definitely a crowd of folks with an impression that you're talking "Linux" like "Ubuntu Linux" or "Red Hat Linux" or "SuSE Linux". As I say, none of you folks has made any attempts to correct that confusion when it's arisen. Android is not "Linux" in the sense that anyone ordinarily uses the term.
Heck, the FSF even counts using glibc as meaning you need to call it
"GNU/Linux," so to at least one vocal group of people all you need is
the kernel to call it Linux. :)
Well, the FSF might be okay with you calling Android "Linux", since it doesn't have any of that GNU stuff in there. In any case, Android could--at best--be referred to, more accurately, as being "Linux-based", or "Linux kernel based". Doing otherwise creates an extremely misleading impression.
Kind of like the "Android is open source" thing, when the only accurate description is "reportedly to be released as open source at some unspecified point in the future".
鏡石
Digit
if there is some misconception, allow me to clarify that we certainly do not try to build something that can run all kinds of Linux goodies. for example most of our system's frameworks are written in Java, and are thus not easily accessible to programs written in other languages. Even though we want to support some other languages in the future, the only officially supported APIs are Java-based at the moment.
vladimir.sch...@gmail.com
languages? There are many variants of ARM instruction set, and many
different phone architectures (e.g. speed of cache and of memory) that
VM with JIT can bring better compatibility and better performance by
adapting dynamically to architecture of individual phone.
Please do not sacrifice current pure Java API in order to allow other
languages. Java is good choice for Android, is commonly known
language, very easy to learn, already used by mobile developers. If
allowed other language, please use C (not C++) (C++ causes size issues
with templates, and STL compatibility in mobile environments is very
bad), and only use C for optimized core functions of applications
(keep UI and application model in Java please).
On Mar 10, 8:06 am, Digit <digit.andr...@gmail.com> wrote:
> I don't think that anyone from Google has even compared Android to a typical
> Linux "system", except for its use of the kernel and a few other libraries
> and facilities. our documentation clearly states that Android is "based on a
> Linux kernel", nothing more fancy than that.
>
> if there is some misconception, allow me to clarify that we certainly do not
> try to build something that can run all kinds of Linux goodies. for example
> most of our system's frameworks are written in Java, and are thus not easily
> accessible to programs written in other languages. Even though we want to
> support some other languages in the future, the only officially supported
> APIs are Java-based at the moment.
>
> > On Sun, Mar 9, 2008 at 9:22 PM, hackbod <hack...@gmail.com> wrote:
>
> > > On Mar 9, 6:45 pm, "Stone Mirror" <stonemir...@gmail.com> wrote:
> > > > 2008/3/9 Guilherme <guilherm...@gmail.com>:
> > > > > Android is linux...
> > > > Not in any usual sense: it just uses a Linux kernel.
>
> > > I guess it depends on what you define as usual -- it is a real Linux
> > > kernel, with a libc and most other standard Unix libraries as you'd
> > > expect. True, it doesn't include X windows, or GTK, or KDE, but I
> > > think it's a questionable position that those things are required to
> > > call something "Linux."
>
> > It seems extremely unclear (if not misleading) to simply refer to Android
> > as "a Linux system". I'm not sure if anyone from Google's been doing that
> > with any regularity, but no one from there has been doing anything to
> > correct people's misapprehensions.
>
> > There's definitely a crowd of folks with an impression that you're talking
> > "Linux" like "Ubuntu Linux" or "Red Hat Linux" or "SuSE Linux". As I say,
> > none of you folks has made any attempts to correct that confusion when it's
Erik Martino
dalvik VM. Then you would have tonnes of code ready to use that would
still be platform independent and doesn't bring the phone down when it
crashes.
Digit
vladimir.sch...@gmail.com
bad applications, also protect applications from one another. Even
with native C code it will be much harder to hurt an Android system
than almost any other system (even desktop systems).
Digit
this means that compiling C/C++ to it is not generally feasible.
but you can envision writing C/C++ code that is called through JNI (useful for a lot of CPU-intensive stuff, while the App UI is still in Java and can use many Java services). and in Android, such a program crashing would only bring down its process, not the whole system.
Diluka Moratuwage
than this. It might help some very nice open source products made in C
to be accessible trough a java interface. I also worked so hard to give
some better Web Services platform for Android, but seems no one else
need that other than me. So sadly gave up the final phase of my attempt,
and no time to waste for that anymore. I found Symbian a very good
place, with fullest support for native development.
Thanks,
Diluka.
Diluka Moratuwage
than this. It might help some very nice open source products made in C
to be accessible trough a java interface. I also worked so hard to give
some better Web Services platform for Android, but seems no one else
need that other than me. So sadly gave up the final phase of my attempt,
and no time to waste for that anymore. I found Symbian a very good
great if Android also provide a bit better support than this.
Thanks,
Diluka.
Diluka Moratuwage
platform inside Android is not available it becomes a very hard job for
a new person to get to know and he might mislead by going through a
normal ARM/Linux toolchain. At the end, it becomes impossible to link
from JNI for sure.
Thanks,
Diluka.
Digit wrote:
> Dalvik respects some of the JVM's memory semantics. you cannot perform
> raw-pointer accesses with it for example.
> this means that compiling C/C++ to it is not generally feasible.
>
> but you can envision writing C/C++ code that is called through JNI
> (useful for a lot of CPU-intensive stuff, while the App UI is still in
> Java and can use many Java services). and in Android, such a program
> crashing would only bring down its process, not the whole system.
>
> On Mon, Mar 10, 2008 at 4:34 PM, Erik Martino <erik.m...@gmail.com
> <mailto:erik.m...@gmail.com>> wrote:
>
>
> Another solution would be to create a C/C++ compiler that targets the
> dalvik VM. Then you would have tonnes of code ready to use that would
> still be platform independent and doesn't bring the phone down when it
> crashes.
>
> On Mar 10, 1:43 am, sbVB <sbvillasb...@gmail.com
Digit
Erik Martino
However you you can come really close with a slightly restricted
language like this one
http://en.wikipedia.org/wiki/Cyclone_programming_language
Cyclone uses tricks ("Fat" pointers) to make pointer arithmetics safe.
It is not completely general, but may get you 95% of the way.
If you want a completely generel C with full pointer arithmatics and
everything there is of course NestedVM which basically compiles C into
a MIPS binary and translates the MIPS binary into Java byte codes
where the memory segments is represented by arrays. It is of course
slow, ~factor 10.
If you really want native access there are other phone platforms that
probably is more attractive like the iphone. The whole point of
android, in my view, is to keep as much as possible in the vm.
On Mar 10, 4:58 pm, Digit <digit.andr...@gmail.com> wrote:
> Dalvik respects some of the JVM's memory semantics. you cannot perform
> raw-pointer accesses with it for example.
> this means that compiling C/C++ to it is not generally feasible.
>
> but you can envision writing C/C++ code that is called through JNI (useful
> for a lot of CPU-intensive stuff, while the App UI is still in Java and can
> use many Java services). and in Android, such a program crashing would only
> bring down its process, not the whole system.
>
hackbod
> If you really want native access there are other phone platforms that
> probably is more attractive like the iphone. The whole point of
> android, in my view, is to keep as much as possible in the vm.
Android. :) We use Java for many purely practical matters where it
gives us a lot more bang for the buck than another language. However,
Android is not at all like a traditional "Java platform" -- the
overall Android system is designed to use and rely on the Linux kernel
wherever it make sense, for example all of our security enforcement is
based on Linux process and user IDs rather than the standard Java
security model.
Part of the reasoning being: we are already sitting on top of a kernel
that provides rich facilities for this kind of stuff, so why duplicate
all of that in Java and take the overhead of enforcing security there
as well? In addition, for killing of misbehaving applications it is
simply much more robust to rely on processes and the Linux kernel than
to try to clean them up purely in the VM.
Digit
we know that all languages/runtime suck at certain things. our choice of Java stems from practical
considerations more than anything else, and we really don't have a religion for it. it has benefits
and annoyances.
let's just say that for what we want to provide, an initial Java path is the one that sucks less :-)
sbVB
http://code.google.com/p/android/downloads/list
I don't think it's a good idea for anyone if Google insists not to
offer a C/C++ SDK. I see 2 futures:
1) the community will develop a "non-official" C/C++ SDK. This is so
much worse than having an official one.
2) the community won't develop anything in C/C++ for Android. In that
case, so much worse for Android. Perhaps we C/C++ developers should be
using Symbian instead, that provides a decent native environment for
us.
vladimir.sch...@gmail.com
"the community will develop the official C/C++ SDK with help from
Google". Is very good option.
On Mar 11, 5:22 pm, sbVB <sbvillasb...@gmail.com> wrote:
> Sources are already public at link belowhttp://code.google.com/p/android/downloads/list
chen yuefeng
| sbVB <sbvill...@gmail.com> |
|
显示详细信息
| 3月10日 (2天前) |
|
|
Hi, all For many reasons, Android MUST have a C/C++ SDK. For instance: I have countess lines of code written in C++ and wxWidgets; of course, I want to compile this to Android. Don't tell me Java is better. I'm focusing in reusing my code. |
..... |
Sean Kelley
On Mon, Mar 10, 2008 at 12:01 PM, Digit <digit....@gmail.com> wrote:
> we don't want to keep everything in the VM. we, the Android team, are *very*
> practical animals.
> we know that all languages/runtime suck at certain things. our choice of
> Java stems from practical
> considerations more than anything else, and we really don't have a religion
> for it. it has benefits
> and annoyances.
>
> let's just say that for what we want to provide, an initial Java path is the
> one that sucks less :-)
I can see the advantage of the VM for third party applications. However, if
one is the actual manufacturer of a licensed Android platform, it seems like
a huge investment to have to rewrite say an already optimized and tuned
application.
In other words, it does not seem very appealing to be required to
re-architect an SDL/Gtk+/fill-in-the-blank application to use the Android
Java UI framework and then somehow re-partition the native code into
libraries that may or may not be easy to combine with JNI.
I can understand the restriction of Java imposed on third party developers,
but I cannot see the benefit for a platform licensee that has an extensive
native code base. I hope such restrictions will go away.
Sean
David Given
[...]
> In other words, it does not seem very appealing to be required to
> re-architect an SDL/Gtk+/fill-in-the-blank application to use the Android
> Java UI framework and then somehow re-partition the native code into
> libraries that may or may not be easy to combine with JNI.
Of course, they wouldn't run anyway because Android phones don't
(AFAICT) have X. And even if you could you wouldn't want to do that
because they wouldn't integrate with the Android UI and the result would
be utterly horrible.
*Any* application that has a UI will have to have a UI written, and
designed for, Android. And that's almost certainly going to mean Java,
because that's what it's written in.
(It may be possible to wrap up all the JNI needed to call into the
Android UI in, say, a set of C++ classes so that you can write a C++ app
that used it; but it would be a repulsive amount of work and would
probably be extremely brittle... and even then you wouldn't be able to
subclass components, so you'd have to write Java code to receive
callbacks. And, frankly, I don't see the benefit; you'll have to rewrite
your UI to fit the Android framework anyway, so you might as well do it
in the preferred language and save everyone a lot of time.)
--
David Given
d...@cowlark.com
Digit
Akio
Is the jni interface of current android binary release code available
or not? Some of my colleges tell me the jni seems not open under
current android binary image. Thank you very much.
Best Regards,
Akio
David Given
[...]
> Is the jni interface of current android binary release code available
> or not? Some of my colleges tell me the jni seems not open under
> current android binary image. Thank you very much.
It is, AFAIK, not available... but it's possible to bodge it
sufficiently to work. Whether it will work reliably, or whether it will
*continue* to work with the next release, is another matter. Watch out
for the dragons.
The error reporting on System.LoadLibrary() is poor; if there are any
unresolved symbols in the .so then all you'll get is an
UnresolvedLinkException saying 'File Not Found'. The most common reason
for *that* is because you're referring to C library or C runtime symbols
that don't exist.
If you go to android-developer and look for the 'Unresolved symbols &
JNI' thread you'll see the various hacks I've done. Some of these might
be of use to you.
*Also*, there's a bug in that the shared library loader on Android fails
to load shared libraries correctly under some circumstances. See #599 on
the bug tracker for more information. This kicks in when you try to take
the address of a member of a global structure that's not the first item.
I did mention the dragons, didn't I?
Good luck!
--
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ─────
│ "I have always wished for my computer to be as easy to use as my
│ telephone; my wish has come true because I can no longer figure out
│ how to use my telephone." --- Bjarne Stroustrup
Akio
Thank you very much.
I'll follow your step to make our own c code module works with android
Java application.
Thank you very much.
Best Regards,
Akio
> 1KDownload
sbVB
> Android UI in, say, a set of C++ classes so that you can write a C++ app
> that used it; but it would be a repulsive amount of work and would
> probably be extremely brittle... and even then you wouldn't be able to
> subclass components, so you'd have to write Java code to receive
> callbacks. And, frankly, I don't see the benefit; you'll have to rewrite
> your UI to fit the Android framework anyway, so you might as well do it
> in the preferred language and save everyone a lot of time.)
for those developers that have already large legacy of C++ code, it's
definitively adequate to have a C++ SDK available. If the process
proves to produce brittle software and thus of little usefulness, only
time will judge. Eventually we conclude just the opposite: that this
is not so difficult and very useful.
The open source spirit is to let developers experience, and see the
results. The Android team shouldn't claim that for some reason Java
"should" be better for the developer. They should give everything to
the developers and let us use the environment the way we like. The
consumer should pick up the software that's really good and useful.
The maximum the Android team could do is to suggest a development path
or instill developers to use certain tools. But not to close the
doors. If doors are to be closed, why choose an open-source
environment. Perhaps some proprietary option would be better in this
case.
sbVB
PowerGUI
I am PowerGUI from Bejing China,I am focusing on Android C/C++ SDK,
I will release the first version within two weeks.
I wonder how many people want to use such sdk.if you need it or like
it,please
tell me.haha.If there are many people will use such sdk,I will fell
very happy,
and will do more work on that.
Best Regards
PowerGUI
----------------------------------------------------------------------
Love Android - Cann't Live Without Android Now
http://www.dotphone.org/english/
windstorm
I am very glad to hear that, please keep your work going and release
it here when you done it, it's meaningful.
--
web: http://www.forwind.cn
msn: likunarmstrong at hotmail.com
sbVB
> I will release the first version within two weeks.
I'd like to know some details of what you're doing.
Option 1 is to write C/C++ code, and use JNI to make it available for
Java.
Then, write the applications using Java.
Option 2 is to write 100% C/C++ (no java) native applications.
I know this is possible for console applications.
But is it possible to write GUI ?
Are there any other options ?
Something else:
are you starting an open-source project of Android C/C++ sdk?
If so, how can I join?
[]'s
----------------------------------------------------
+------+ Sergio Barbosa Villas-Boas
/------/| sbvill...@gmail.com (new email!!!)
| sbVB |/ http://www.sbVB.com.br
+------+ Skype: sbvbsbvb
Valluri Kumar
Dear PowerGUI
I will be very much interested to use the same , If available
****************************************************************************
****************************************************************************
*************************************
This e-mail and attachments contain confidential information from HUAWEI,
which is intended only for the person or entity whose address is listed
above. Any use of the information contained herein in any way (including,
but not limited to, total or partial disclosure, reproduction, or
dissemination) by persons other than the intended recipient's) is
prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!