Database Info

Forthcoming Native Development Kit

A week ago Brian Swetland (of the Android team) posted to the g1-hackers mailing list this juicy little nugget:
It is possible to bundle native shared libs in apks, and specific details
about how to do this in a least-likely-to-break-later way will be documented
in the forthcoming Native Development Kit (NDK).
Work is on-going to improve the platform APIs and provide more and better
access to the OS and hardware (bluetooth, improved audio, etc, etc). Future
updates will increase the surface area of the APIs.
Click to expand...
Click to collapse
Trying to get some confirmation and additional details, I checked in with android-framework and received this reply from Dave Sparks:
Yes, we're planning a native SDK. There is no official release date
yet. The initial release will probably be very limited in scope, just
enough to add some JNI helpers. As we lock down native API's, more
functionality will be added.
Click to expand...
Click to collapse
"JNI helpers" sounds a bit underwhelming, like .so libraries for optimizing inner-loops. However, this looks like a good first step toward getting applications with performance-bound modules to shine on Android. Personally I'm crossing my fingers for this to be what the Mozilla Fennec team to invest the time in porting for Android.

I'd rather see C#/.NET bindings for Android. Java blows. When I have time, I'm going to look into cross compiling mono for ARM (it's been done for ARM PCs, but not for Android yet).

Koush said:
I'd rather see C#/.NET bindings for Android. Java blows. When I have time, I'm going to look into cross compiling mono for ARM (it's been done for ARM PCs, but not for Android yet).
Click to expand...
Click to collapse
At first I thought you meant to cross-compile C# to Java bytecode to run in Dalvik. Didn't seem to make much sense since you wouldn't benefit from the .NET framework itself at all.
As for getting Mono natively on ARM, would that work for a non-root G1? If not it would be of little help for developing applications for the general non-rooted public.

NDK 1.6 has enabled QT & KDE apps (natively) for Android Devices

So they claim:
Source: http://www.kdedevelopers.org/node/4070
More on NDK: http://android-developers.blogspot.com/2009/09/now-available-android-16-ndk.html

That post does not claim anything. The person simply says it is possible for Qt to run with the NDK. NDK 1.6 has not enabled anything directly.

Qt? heh. I h8 qt. It has a real childish look about it. Qt die die die.
GTK would be nice. Most real apps use GTK. It would really open a lot of doors for using REAL software, i.e. though openoffice would be a bit too much of a HOG, abiword (which is a very nice *and light* word processor) should work (system requirements below) along with other similar software (spreadsheet, etc.). And the good news is that the same things that would allow Qt would also allow GTK.
AbiWord System Requirements:
GNU/Linux, BSD, Solaris (2.6, 7,8,9,10), AIX, HP/UX (10.20, 11.0), OSF/1, Tru64:
* GTK+ 2.2 or newer (2.2.4 recommended)
* At least 16MB RAM (embedded systems probably won't require more than 8)
* Any processor that supports any of these operating systems (which is effectively, any processor)
* Optionally GNOME 2.2 (2.4 recommended)
Click to expand...
Click to collapse
Anyone feel like helping out with a fun new project?

Note: I don't see anything in the 1.6 version NDK that would make Qt or GTK easier... in fact, it still looks like a nightmare.

JIT in Dalvik JVM

Hello,
Do you know that it is possible to enable JIT in Dalvik JVM?
http://groups.google.com/group/0xlab-devel/browse_thread/thread/1edef26f4e5b7427
According to the Dalvik developers it is possible to backport JIT to the Donut tree and gain ...1.74x in performance!!! It would be awesome if someone could spend some time and create a ROM with that patches applied.
Anyone?
Karol

I think you misread somewhere.
It is a *new feature* they are *adding in*. The current JIT in AOSP/master is in development (i.e. incomplete). You can play with it if you want, but you should consider this to be a future new feature that will be added to official builds.

Well, I though that this is xda developers forum, place where even experimental Android features are welcome (vide extra memory hack and others...
And while English is not my native language I doubt that I have misread it. The current master tree ALREADY contains JIT implementation PLUS there are patches which allow using it in the Donut tree. So even though it is experimental it is worth checking out because it apparently it can be compiled and tested...
I would do this by myself, but since a week or so I am unable to update my donut tree, I am getting "fatal: The remote end hung up unexpectedly" messages

The current master branch in AOSP is eclair. If you use repo to sync the AOSP source, then build, the branch it pulls out (according to the output from envsetup and the lunch menu I receive) is eclair (2.0). I doubt that the donut branch has the code for the Dalvik JIT.
It *may* be possible to backport it to donut (1.6), but why when 2.0 is running on the Dream except for some AV/codec issues without problem?

Let me quote developers behind JIT in Dalvik....
NOTE: the results were measured in Donut based environment. That is,
there are some changes for Eclair backport to Donut without replacing
the libcutils and bionic, which were modified a lot in Eclair.
If you would like to introduce Eclair's Dalvik VM in Donut based
products (especially for 3rd-party components compatibility), feel
free to apply the attached patches and rebuild Android.
Here are the instructions:
# cd android-donut
# mv dalvik dalvik-orig
# . build/envsetup.sh
# git clone git://android.git.kernel.org/platform/dalvik.git
# cd dalvik
# git apply dalvik-eclair-backport.patch
# mm
# cd ../frameworks/base
# git apply frameworks-base-eclair-backport.patch
# mm -B
# cd ../../
(Do copy out~system to your target.)
Click to expand...
Click to collapse
This is from the link I pasted in my first message...
And why? Well, because there will be no full Eclair build for G1 until HTC releases some closed source components which currently doesn't work with the Eclair kernel. So this is still worth trying out, I doubt that those components will be released in near future...

karolbe said:
Let me quote developers behind JIT in Dalvik....
This is from the link I pasted in my first message...
And why? Well, because there will be no full Eclair build for G1 until HTC releases some closed source components which currently doesn't work with the Eclair kernel. So this is still worth trying out, I doubt that those components will be released in near future...
Click to expand...
Click to collapse
Ah, I stand corrected. It looks like it is indeed workable to get 1.6 with a JIT Dalvik. However, once HTC (or Qualcomm) releases the needed A/V drivers, 2.0 will be fully functional on the Dream. But, this might be nice in the interim.

Is that just the Eclair Dalvik version, or is it also the JIT-enabled Eclair Dalvik?
There /is/ a difference between the two.

I've had the JIT-enabled Dalvik running for a bit (on CM 4.2.5), but it's a memory hog and has a weird performance profile. It will shave 4 seconds off your "Benchmark PI" score, but interactivity of the device suffered. And it crashes sometimes.
If you want to try it (CM-4.2.5 only), here's a copy of the file:
http://n0rp.chemlab.org/android/testing/libdvm.so

Yeah, I tried it out, and the phone seemed to be less responsive. When I tried to install an app the phone rebooted, and now it seems to be booting to a certain point and then shutting down again. Nice progress though.

cyanogen said:
I've had the JIT-enabled Dalvik running for a bit (on CM 4.2.5), but it's a memory hog and has a weird performance profile. It will shave 4 seconds off your "Benchmark PI" score, but interactivity of the device suffered. And it crashes sometimes.
If you want to try it (CM-4.2.5 only), here's a copy of the file:
http://n0rp.chemlab.org/android/testing/libdvm.so
Click to expand...
Click to collapse
Memory Hog.
That's what I was afraid off, that a JIT would hog memory. And if there's 1 thing that my G1 is really short of, it's memory. RAM for running applications. So no please no more memory hoggging on my G1! ;-)
I'm afraid that memory hogging is kind of unavoidable for a JIT.
Just my 2ct.
--Tim

Anyone tried this with the memhack and CompCache running?
EDIT: Running it myself now. Can't see any lagginess; everything seems to be running quite snappily. Going full-time with it now.

I haven't done any java stuff for a while, so I might be off. Anyways, since this is a vm library change, I assume it runs in mixed mode (dynamnically compiles the java byte code when needed), which may cause performance issues. Is there a way for us to pre-compile all the java code in the apps with jit? and have the apps run natively without the dalvik vm at all? This would be the most desirable. I think the biggest weakness in android is the dalvik vm. It is a huge memory hog. If we can use jit to compile the apps into native instructions then theoretically we shouldn't need the vm to run at all.
If this jit is run in mixed mode, if it is done correctly it should still help. You should see performance increases on the second time you run the app.

If this jit is run in mixed mode, if it is done correctly it should still help. You should see performance increases on the second time you run the app.
Click to expand...
Click to collapse
Umm... that's just not how JIT interpreters work.
Seriously -- JIT compilers don't change the core data of the application at all; they just translate bytecode into machinecode within the runtime environment in order to speed up the execution of frequently-encountered "strings" of code within the application as they are encountered.
Seriously: try this link [ http://psyco.sourceforge.net/doc.html#how-does-it-work ] to get a better understanding of why what you just suggested displays a bit of ignorance regarding the topic-at-hand.

A bit of ignorance is a compliment. Like I said I have not done any java work for a long time. What I don't understand about jit the way it is done, is why not go all the way and generate the native code similar to the odex files, and just by pass the vm all together. If they are going to the trouble of compiling byte code into native instructions anyway.. why not just do it once and get it over with instead of compiling it over again and again... for short running tasks like most apps on android, it may very well be a perf hinderance.
IConrad01 said:
Umm... that's just not how JIT interpreters work.
Seriously -- JIT compilers don't change the core data of the application at all; they just translate bytecode into machinecode within the runtime environment in order to speed up the execution of frequently-encountered "strings" of code within the application as they are encountered.
Seriously: try this link [ http://psyco.sourceforge.net/doc.html#how-does-it-work ] to get a better understanding of why what you just suggested displays a bit of ignorance regarding the topic-at-hand.
Click to expand...
Click to collapse

why not just do it once and get it over with instead of compiling it over again and again... for short running tasks like most apps on android, it may very well be a perf hinderance.
Click to expand...
Click to collapse
Well, I can think of a few reasons.
1) High-level programming languages are just plain easier to write for. Python, for example, uses an interpreter (VM) as well -- though you can compile it once and be done with it. High-level languages, as such, typically don't compile well because of the lack of "symmetry" that you get between higher-level languages and actual machine code. (Remember, my friend, the The Story of Mel )
2) JIT compilation in interpreters get you //near// compiled performance from non-compiled code. In other words; you write the program to the VM once. The VM then gets compiled one time for each platform, (Remember; despite being essentially the same hardware the Dream is somehow two different boards each of which would require a separate compile... :/) and this will only get worse over time. Now, the programmer doesn't have to specifically call up devices based on the platform but rather on the VM. He doesn't have to re-compile for each CPU/integrated-board circuit. You don't have to store, for example, one version of an app for Dreams/MT3G's, one for Heroes, one for Droids... and down the road, one for the MIPS chips, etc... Saves massively on storage considerations for centralized distribution repositories like the Market itself is.
3) VMs can be functionally isolated, preventing most forms of malicious program code escalation. Sandboxing programs is far easier when those programs are running in their own VMs. Each program/task is initiated within its own VM, which makes initialization and garbage-cleanup rather simple. For such an open-to-communications platform as a mobile phone, that can only be a good thing. Natively compiled code typically doesn't play so well with such sandboxing.
Those are just the thoughts off of the top of my head. I feel it important to note that IANAP.

I'm trying the libdvm.so cyanogen posted on my 32A magic (288MB of RAM) and so far it's all working well, and it seems much faster

Using 4.2.5 on 32A Magic with 4.2.4 Radix Kernel with New JIT Based libjvm.so
Everything Works Well and Never had any Force Close but is that 4.2.4 Kernel from Radix actually uses JIT.
@cyanogen 32A have 288 MB ram i can test JIT based Dalvim if you want me to test it

Ok, I integrated this lib with Cyan 4.2.5. Running comp-cache and Ram hack, 16GB class 2 SD.
Initial impression (based on 20 minutes of playing);
No change in OS speed. No crashes yet. Apps (especially game emulators) have a noticeable increase in speed. I have no technical information to back up my claims, nor do I have the possibility of an ABX comparison. Sorry.

Thanks for the explanation, I buy #3 as far as security is concerned, we all know those virus taking advantage of overflow instructions in windows. But As for #2 I don't mean to have developers compile the byte compile to native, but have the vm on our phone compile it on first run and save the native instructions in file similar to how it generates the dex files on first run. This way it'll not have to recompile every time it runs. I just wish there is a way to avoid the dalvik-vm.
I irks me how much memory the dalvik-vm hogs up. A simple battery widget takes 12-16mb of memory.. It has a few pics and bytecode that simply goes to the system driver go get a number. I mean the whole ext3 filesystem driver uses less memory. Same with those widgets for task killing, they take up well over 10 mbs, which kind of defeats the whole purpose. I could write a simple tiny script that uses kill and do the same job without taking up 10m+ in the background.
We all here complain about our hardware, but I feel like these are more of software problems. anyways, that's just my rant... i hope the memory issues in vm gets better in later release.
IConrad01 said:
Well, I can think of a few reasons.
1) High-level programming languages are just plain easier to write for. Python, for example, uses an interpreter (VM) as well -- though you can compile it once and be done with it. High-level languages, as such, typically don't compile well because of the lack of "symmetry" that you get between higher-level languages and actual machine code. (Remember, my friend, the The Story of Mel )
2) JIT compilation in interpreters get you //near// compiled performance from non-compiled code. In other words; you write the program to the VM once. The VM then gets compiled one time for each platform, (Remember; despite being essentially the same hardware the Dream is somehow two different boards each of which would require a separate compile... :/) and this will only get worse over time. Now, the programmer doesn't have to specifically call up devices based on the platform but rather on the VM. He doesn't have to re-compile for each CPU/integrated-board circuit. You don't have to store, for example, one version of an app for Dreams/MT3G's, one for Heroes, one for Droids... and down the road, one for the MIPS chips, etc... Saves massively on storage considerations for centralized distribution repositories like the Market itself is.
3) VMs can be functionally isolated, preventing most forms of malicious program code escalation. Sandboxing programs is far easier when those programs are running in their own VMs. Each program/task is initiated within its own VM, which makes initialization and garbage-cleanup rather simple. For such an open-to-communications platform as a mobile phone, that can only be a good thing. Natively compiled code typically doesn't play so well with such sandboxing.
Those are just the thoughts off of the top of my head. I feel it important to note that IANAP.
Click to expand...
Click to collapse

cyanogen said:
I've had the JIT-enabled Dalvik running for a bit (on CM 4.2.5), but it's a memory hog and has a weird performance profile. It will shave 4 seconds off your "Benchmark PI" score, but interactivity of the device suffered. And it crashes sometimes.
If you want to try it (CM-4.2.5 only), here's a copy of the file:
http://n0rp.chemlab.org/android/testing/libdvm.so
Click to expand...
Click to collapse
Could anyone upload that again? The link is dead.

Why so few Android apps compiled for MIPS?

This is something that is driving me crazy, shouldt be MIPS Android SDK and NDK be compatible with any source maded for the ARM version?
First thing i noticed with this Ainol Novo 7 Basic was that, the small amount of compatible apps, none of the better apps are compatible.
No: Netflix, Skype, Android Terminal Emulator, MX video Player, Chainfire3D, any mame32/nes emu, a working barcode reader, connectbot, adosbox/qemu, opera or any other browser. and the list goes on.
I wonder why, i trought devs will want the larger amount of users as posible.
For the record, i just got Android Terminal Emulator working in my Novo 7 Basic, i had to:
1) Download Term source code
2) Download MIPS Android SDK, NDK, Apache ANT, Eclipse with ADL, cgywin (to compile NDK libs)
3) Import Term project to eclipse
4) change the target build to android-12
5) change Aplication.mk to "APP_ABI := mips mips-r2"
6) build ndk-libs for the app
7) build the project with eclipse
And i know nothing about programing for android, just c/c++

Best guess that anyone will probably give you is that the majority of devices out there running Android are ARM based, but as that changes, the number and quality of available apps should improve.
There is a HUGE obstacle to overcome however. Not many people are going to buy a device today based on what might run on it months from now, especially when there are devices out there that will run it now, and many of those that do purchase a MIPS based device consider it a mistake and end up returning it.

It is not possible to offer two different version on the market and i don't think it is possible to restrict the apps to a specific architecture.
Are the number of MIPS devices really rising? The android market doesn't really seem to be ready for that. It would mean even more app versions devs would have to consider.
Which apps work and which don't?
Maybe those using native code, compiled with NDK don't work, as those routines are compiled specificly for ARM.
Don't take my word for it though, just some thoughts.

its not possible to get 2 different versions on the market.

Rumor has it that the problem is frequently a development oversight and that it's related to omitting some important MIPS related files from the package build.
I imagine that it can also be related to poor programming practices and also programming for optimized code.
~~ Sent from my Velocity Micro Cruz PT701/T105 via Tapatalk ~~

As far as I know, Market supports device specific apk's nowadays, which would make it possible to have an mips apk...
http://developer.android.com/guide/market/publishing/multiple-apks.html
Altough the proccess is not trivial, it is not that difficult either, just minor changes to the manifest and filter the apk for Native Platform...
Also, it would be possible to compile it for all devices that the current NDK supports, by using the latest revision of NDK (as of November 2011):
http://developer.android.com/sdk/ndk/index.html#overview
You just need to add:
APP_ABI := all
Click to expand...
Click to collapse
to the makefile and it should now be compatible with all processor architectures that NDK supports....
So, now there are means to easily support different processor architectures, but, don't expect quick adoption of it, as, unfortunately, this depends entirely upon developer will to change some of its project settings and/or publishing way (it is entirely possible, now, to have a single apk for all platforms)...
Unfortunately, right now, and I would dare to say, in the next 6 - 8 Months, I would not expect this to change much... Altough the official NDK has support for multiple devices, it still doesn't incorporate the MIPS abi, which is not official, and thus, it is not possible to declare that an APK for a native MIPS device as well...
Hopefully MIPS devices will grab a nice piece of the Android devices and then "force" Google to officially support those devices. I believe that it is possible to grab the latest unoficial NDK and use it with APP_ABI all and publish it to the Market, but, as of today, is mostly something recent and that few (if any) developers support (remember, this possibility came with November's NDK, I'm not even sure if MIPs NDK is already up to date with Google's November NDK), so, I would dare to say, MIPS devices are not in a good position right now (even x86 devices, which have official support, are not...).

I have a MIPS based tablet named "MIDI Japan MD-785IP" that is quite nice but is making me sad with the lack of some softwares and in special, lack of ROMs to it. Apparently I am the only person in the internet that have one

shivansps said:
This is something that is driving me crazy, shouldt be MIPS Android SDK and NDK be compatible with any source maded for the ARM version?
...
For the record, i just got Android Terminal Emulator working in my Novo 7 Basic, i had to:
...
Click to expand...
Click to collapse
Hello,
Have you shared that MIPS compatible Android Terminal Emulator?
Thank you

Sure... and here is connectbot too.
Ive attemped to recompile adosbox too but the source code and makefiles are just a big mess and no documentation provided.
And that is another problem, poor documentation in open source projects.
BTW, Market has to have some way to know if a app is for arm or mips, since market on basic only shows up compatible apps.
Also, its no enoght to just incluide the "mips" folder along with "armabi" with all mips compiled .so files inside the libs folder? because is that all what it takes, unless the app is using binaries.
And im agree that google has most of the fault for not incluiding mips supprt in his NDK, the mips one can compile for both.

I wonder what will happen when intel medfield will came out...

I am in an even worse position - I bought 2 NOVO7Paladins - one for the g/f. I had to get one for myself, because I know I will be 1st line support
So, I have a MIPS cpu (with reduced software availability) and also ICS which further reduces app compatibility.
Apps which I consider essential (Samba server, VNC Server, Angry Birds Seasons....) are not available, so l'm currently installing eclipse, JDK, SDK, NDK on a linux box to try to rebuild stuff - it has been many years since I last had to get my hands dirty with code.
I know I have a steep learning curve ahead, but I'm sure it will be many months before there is a significant increase in app availability. I understand though, that if developers have written native code for ARM, they won't be in a hurry to port that to a minority cpu. It is way easier for new apps to be built with different architectures in mind.
Thanks Shivansps, I had been looking for a terminal - I had given up and was trying to get telnet working - a last restort. It was either that or carry a laptop around with me to use ADB
Now, all I need is to get the MIPS ABI to appear in Eclipse AVD setup... (oh, and learn how to code for android )

i dont use Eclipse or SDK myselft any longer, what i do is just recompile shared libs with mips NDK and include the new "mips" folder intro the libs folder of the original .apk file, then re-sign the apk with one click signer.

MapsWithMe for MIPS and x86
maersi said:
I am in an even worse position - I bought 2 NOVO7Paladins - one for the g/f. I had to get one for myself, because I know I will be 1st line support
Click to expand...
Click to collapse
Hi! Do you still have MIPS android device?
Would you please test MapsWithMe on it? It's offline world maps based on OpenStreetMap.
We've built apk for mips and x86 architectures but doesn't have any devices to check if it works.
Apk is available here: dl.dropbox.com/u/24013616/MapsWithMe-203-mips-x86-120502.apk
Cheers,
Alex Zolotarev
MapsWithMe Team

AlexanderZolotarev said:
Hi! Do you still have MIPS android device?
Would you please test MapsWithMe on it? It's offline world maps based on OpenStreetMap.
We've built apk for mips and x86 architectures but doesn't have any devices to check if it works.
Apk is available here: dl.dropbox.com/u/24013616/MapsWithMe-203-mips-x86-120502.apk
Cheers,
Alex Zolotarev
MapsWithMe Team
Click to expand...
Click to collapse
Yes, I still have a mips tablet, but it hasn't gps. Do you want me to check it?
Enviado desde mi ThL W8 usando Tapatalk 2

[PROJECT][PORT] GNU CoreUtils on Android v1

-> About
Busybox is a good set of common Unix utilities but the utilities are all striped down version of original ones and they provide less features ; So you may need the original utility with full features for your App or cmd-line ,therefore you should use this project !
`Core Utils on Android` project provides most GNU Core Utils for Android devices. they may be invoked from Android Apps or from command line terminal.
All utils has been compiled with Linaro GCC 4.8.1 (Hardware floating point ABI) and O3 optimizations and with Musl LibC to provide best performance.
-> Disclaimer
THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY
APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT
HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY
OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO,
THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM
IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF
ALL NECESSARY SERVICING, REPAIR OR CORRECTION.​
-> Requirements
an ARM v7 processor with built-in NEON SIMD (scorpion, krait, exynose 4, exynose 5,...)
-> Installation
Be sure you meet the requirements !
Get the zip file
Flash it via recovery mod
Reboot and enjoy
-> Usage
To avoid issues of having busybox and coreutils at same time , all utils are named in form : cu.${UTIL_NAME} for example :
cu.echo "hello world!"
or
cu.chmod 644 /system/build.prop
and use this form for invoking any utility !
to see how to use utilities , take a look at GNU CoreUtil documentations.
-> Bugs
a few utils such as ls and uname are broken down till I fix them and add the correct one to repository.
some utils are missed. ( currently we have 103 applets working)
-> Download
** CoreUtils on Android v1
initial release . we have 103(working) + 2(not working) utils now
-> Source
https://github.com/alireza7991/coreutils

reserved ;

Very cool! I'll be keeping an eye on this project.
(Edit: Don't want to be that guy, but... First!)
Sent from my Nexus 10 using Tapatalk

tb01110100 said:
Very cool! I'll be keeping an eye on this project.
(Edit: Don't want to be that guy, but... First!)
Sent from my Nexus 10 using Tapatalk
Click to expand...
Click to collapse
and maybe last .

congratulation !
i hope you became more successful

Congratulation Alireza:good:

always something new.
congratulation littleBig man.

Wow very nice. Subscribed!!!!
Thanks mate!!

Since I'm in an impulsive state at the moment, I'm going to go ahead and say...
Edit: I misread the OP, I have a north American gs3.... Damn you Samsung and your favoritism with international versions.
I has a sad now.
Anyways, I really hope development flourishes for this project because this interesting..

Time to give this great project more attention

wow
a great iranian dev here
installing it on my play now
it seems to be great

So I take it that this isn't compatible with the Snapdragon 800?
Sent from my SM-N9005 using Tapatalk

i think it is as snapdragon s800 is krait ( ARM v7 processor with built-in NEON SIMD )

This is actually a great project. I might implement these in a ROM... Whenever I decide to make one.
Sent from my 2013 Nexus 7 using Tapatalk Pro

hi Alireza,
this poject sounds very interesting, I'm just surpised that there's not more incomes.
i ll spread the word and looks further to your git.
thanks :good:

fragargon said:
hi Alireza,
this poject sounds very interesting, I'm just surpised that there's not more incomes.
i ll spread the word and looks further to your git.
thanks :good:
Click to expand...
Click to collapse
Especially with this thread being featured on the xda portal today.
[poo]

Really cool project. I'm taking a look. It would be nice if mfgs started encorperating GNU CU like every other Linux distro. I like the core utils.
The only problem is the CU is so big in comparison to BB. I have a project called CASUAL and for minimal space, i can include both ARM and x86 variants of busybox.
Don't get me wrong though. CU is my favorite toolset. I prefer it over all others.. Especially stock android. Thanks for your work in bringing this to Android. Hopefully AOSP takes note

Very, very cool! GNU CoreUtils is, by far, my favorite set of core command line tools on Linux. It's really awesome to be able to use them on Android.

AdamOutler said:
Really cool project. I'm taking a look. It would be nice if mfgs started encorperating GNU CU like every other Linux distro. I like the core utils.
The only problem is the CU is so big in comparison to BB. I have a project called CASUAL and for minimal space, i can include both ARM and x86 variants of busybox.
Don't get me wrong though. CU is my favorite toolset. I prefer it over all others.. Especially stock android. Thanks for your work in bringing this to Android. Hopefully AOSP takes note
Click to expand...
Click to collapse
I built this with eglibc first time, and it was around 50MB but with musl libc it's 8 MB now! Busybox is about 2MB while being linked with eglibc. and toolbox is 100KB
Busybox is smaller because it is a multi call binary so utils will share their code but in coreutils all utils are built in a single ELF. another reason is that coreutils has a special part which does some libC functions to make coreutils more compatible with different c libraries, this will increase size by 100-200 KB and there is no way to omit them however I 'm working on this
pedyvirus said:
i think it is as snapdragon s800 is krait ( ARM v7 processor with built-in NEON SIMD )
Click to expand...
Click to collapse
exynose 5 family + exynose 4 + scorpion + krait familiy + tegra 3 are completely supported.
armv6 and tegra 2 family may fail in execution .
Sent from my GT-I9001 using Tapatalk

@alireza7991, is an APP for this awesome toolset planned?