Related
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
Hello people,
after some conversation with early ICS-on the transformer developer paulburton, I have a git repository of a mostly working linux 3.1 mainline kernel with some patches from paulburton to make it actually work.
Icluded are (as of now) :
improved atmel mXT1386 touchscreen driver
tegra_v4l2 camera driver
ov5640 soc camera driver
prox_lds6202 proximity sensor driver
fm34-500 voice processor driver
asusec keyboard driver (for dock)
al3000a ambient light driver
The purpose of this is not to port things back from some linux 3.X kernel to our 2.X kernel, but to have a fully working 3.X source tree some day, from which we could port to further linux versions in the future. This can also be helpful if we want to port android 5.X in the future.
The github is at https://github.com/skirata/linux/tree/android-tegra-tf101-3.1 .
(It's my github, if someone wants to become a collaborator, please let me know, I'll add you to the collab list.
WE NEED EVERY DEVELOPER WE CAN GET.
I will spend some time on this, but I think I can hardly finish this project on my own.
Totally support this, looks promising!
Thanks for the initiative.
Are you and guever working on this together? I can test and maybe help make aokp or megatron versions.
Sent from my Transformer TF101 using Tapatalk 2
Of course I'm willing to work, you know I've helped all I could.
My kernel has much of the code updated to 3.1, so may be we can use much of it.
This can be done in two ways, by modifying the code in paul whatever it takes, or modify mine. I have nothing clear which will be easier, because over time I have made several test on my code and unfortunately, when the kernel does not boot can not be debugged, so you have to turn back.
Until wednesday I will not be able to devote almost no time, so I think the first thing would be to check the operation of the kernel of paul (if not already done) with a current rom.
It is possible that the graphics drivers (most are binary system level) may not work with that kernel.
Well, it is what I think, that first we must see is what should be changed in the kernel to function properly (or whether to change the rom).
Teamwork is how it's meant to be done.!
I will setup a working kernel konfig in the next days to push this a little forward.
at Guevor :
I'm adding you in as a collaborator so we can work together on this.
Let's improve paulburton's drivers and add new ones based on latest nvidia images.
The advantage of upstream-porting rather than downstream-porting is we can port future kernel versions more easily with own written drivers.
Also, android 5.X porting will be a lot easier, as I think it won't support 2.6.X kernels at that time. And even if it would, we can have a massive performance boost if using 3.1 mainline kernel with improvements all over the world.
Glad to count you in, guevor.
I owe you so much already.
EDIT : Just in case, be sure to use the 3.1 branch of the linux repository, as the master branch is forked from torvalds (linux 3.4.X) and will get some love when we get the 3.1 kernel to work as good as we are satisfied.
Well, the main problem I see, thinking about future versions (5.x) is that we do not have the source code for video drivers, only a small part that exists in the kernel. This added to the fact that nvidia does not provide (at least I do not know) the binary drivers for android (as they made for linux), I think that may be, we do not see tegra2 drivers for 5.x. That does not mean we can not do something, but will be less optimal and more complicated.
Hopefully I'm wrong and nvidia make things easy , but I think no manufacturer will use tegra2 for new products, and do not think they will update current products to that version ....
guevor said:
Well, the main problem I see, thinking about future versions (5.x) is that we do not have the source code for video drivers, only a small part that exists in the kernel. This added to the fact that nvidia does not provide (at least I do not know) the binary drivers for android (as they made for linux), I think that may be, we do not see tegra2 drivers for 5.x. That does not mean we can not do something, but will be less optimal and more complicated.
Hopefully I'm wrong and nvidia make things easy , but I think no manufacturer will use tegra2 for new products, and do not think they will update current products to that version ....
Click to expand...
Click to collapse
Have you tried contacting Nvidia about this?
For the record, I am not a Linux user, even with what Im going to say, keep that in mind... My history is firmly routed in WinBlows land!
This has me all sorts of excited, I remember saying it back in paul's thread before it fell off the face of the earth (read, first few pages of the forum).
As stated at the top, while NOT a Linux user, I was trying to build CM9 for one of my tablets, to do so, I had setup a Linux box (tried a few distro's), and kept having issues, so a friend of mine walked me through updating to a 3.4.x kernel (3.4.0.-5 iirc), and things definitely FELT smoother vs the 3.0 (on the distro I was using before he berated me for it and moved me to a different one) and then 3.2 kernel in use (ill note hardware issues where also at play with the actual issues, but the smooth feeling after updating was definitely something I noticed).
I have no benchmarks or performance statistics to back that up, but as I said in paul's thread, and have now experienced in a "full" Linux environment, the future with Kernel v3.1 and up has me VERY excited as to what can be done with the OG Transformer! (vs mass backports to 2.x)
On that note, Subscribed thread, and time to get an RMA for my Tablet... the top basil part is starting to come off the unit
I haven't coded a lot with linux and android source, but I do have experience with coding and especially with reading through source code and finding syntax and other errors i.e. proofreading
So if you want me on the team I'm game!
Orkeren said:
I haven't coded a lot with linux and android source, but I do have experience with coding and especially with reading through source code and finding syntax and other errors i.e. proofreading
So if you want me on the team I'm game!
Click to expand...
Click to collapse
Every help is welcome !
Please tell me your github name and I will add you as a collaborator
If my help is welcome i am willing to test your builds on my TF101G B90 with dock. So let me know if you have to do something.
ajohn117 said:
If my help is welcome i am willing to test your builds on my TF101G B90 with dock. So let me know if you have to do something.
Click to expand...
Click to collapse
Will do for sure, but it could take some time until we can push out the first build for testing.
rayman33 said:
Hello people,
after some conversation with early ICS-on the transformer developer paulburton, I have a git repository of a mostly working linux 3.1 mainline own.
Click to expand...
Click to collapse
With my git every things works but usb hotplug,cam,hdmi-audio. ( usb works fine when insert add boot ) , also i will stop dev for it as i'm selling my tab :crying: but would be nice if this got finished.
also major thanks to paul
Do you started the project?
I tried some things yesterday, but it did not boot. I will have a look into spark rom and try some other things, I think I have some ideas.
Btw, kernel compiles fine, zImage is there, perhaps some early device drivers have to be updated. I will look into the ramdisk I created and fix some things ...
Just to let you people know. Progress is being made.
First progress
I managed to make it boot on revolver 4.1.1 rom. I modified the video drivers to be compatible with the actual binary drivers.
The touch screen is not working, but I really have not looked at it, maybe even compile options I chose are not the most adequate, but just wanted to get it to boot with video graphics working.
We better get each other updated via pm in the future ..
What touchscreen driver did you define in the kernel config ?
The new mxt1386 or the old one from the 2.6.39.4 kernel?
Maybe we need to rewrite the mxt1386 drivers.
rayman33 said:
We better get each other updated via pm in the future ..
What touchscreen driver did you define in the kernel config ?
The new mxt1386 or the old one from the 2.6.39.4 kernel?
Maybe we need to rewrite the mxt1386 drivers.
Click to expand...
Click to collapse
Well, I tested whether simply boot and graphics drivers failed as expected, and I've tried to change it and make it working. I think that is the basics (make it boot) to further adjust problems.
About the drivers, yes, I used mxt1386 but not detected coordinates, just click. I used a USB mouse to verify that the graphics drivers work.
I updated the repository with my changes.
Did you get a log cat already ?
It may reveal if the mxt1386 driver fails to load.
rayman33 said:
Every help is welcome !
Please tell me your github name and I will add you as a collaborator
Click to expand...
Click to collapse
easy as pie!
Code:
orkeren
I have been reading some of the items about people modifying ROMS, porting ROMS, etc. and I am not certain if I have all of the terminology correct. I am wondering if there is some type of architecture definition or diagram that would indicate the different parts of a ROM.
I found one web post that broke items down to kernel, libraries, bootloader, recovery, radio, framework, core, android runtime. What I don't know is what kind of correlation there is between a framework and runtime to a kernel. Is this a situation like Linux where you have a kernel with all of its drivers and you would run the Android GUI on top of that and any version of the Android GUI is going to work with pretty much any kernel, or is there some type of match-up between a kernel and specific versions of Android?
I have an Elocity A7+ which uses a Tegra II 1ghz dual core CPU. It was only built with Android 2.2. It seems like this tablet should be able to run ICS fairly well since I have seen a number of single core tablets running it. The manufacturer made the kernel source available for this tablet, but what I don't understand is if it is possible to build the ICS framework and runtime with this kernel.
Without detailed information it would seem to me that the kernel is taking care of interfacing directly with items like the touch screen, the camera, the audio system, the buttons, the wi-fi, etc. Do requirements for kernel interfaces change from android version to android version or can an ICS framework communicate with the kernel from a 2.2 device? Is there any kind of documentation that indicates what kernel calls have to be available to the different Android versions?
I apologize if I am not asking the right questions.
The general idea is to free the kernel from needing the source for every build.
The kernel currently uses DTB, but even that is included in the kernel source.
make tegra11_android_defconfig -j$CPU_JOB_NUM ARCH=arm CROSS_COMPILE=$TOOLCHAIN_PREFIX
make tegra114-roth.dtb -j$CPU_JOB_NUM ARCH=arm CROSS_COMPILE=$TOOLCHAIN_PREFIX
make -j$CPU_JOB_NUM ARCH=arm CROSS_COMPILE=$TOOLCHAIN_PREFIX
This has not been verified without the source already downloaded, but the general idea is to move toward being able to produce kernel packages with just the kernel repository.
https://github.com/StarKissed/roth-kernel-starkissed
Had to fix some make issues running a mac, but I'm hoping to have a build out soon.
Many of the changes come from Tegra 3, due to the lack of Tegra 4 devices, and will have to be tuned. This may lead to some initial instability.
The source was temporarily made private until it is fit to compile. This was done to prevent erroneous reports that it's broken when the issues are known and just require the time to address them.
Are you going to compile custom kernels and release them to public?
Antara33 said:
Are you going to compile custom kernels and release them to public?
Click to expand...
Click to collapse
When I get time. Right now there is a little too much going on already.
The source and commands may work but with using a Mac, even a source build results in loops, so I have to resolve that before saying it does the same thing.
After an interesting conversation, the mpdecision idea is pointless. I bought into the belief that it might be interesting to test an alternative, but the shield thermal control has been extremely well-designed.
The primary focus will be simply unlocking additional kernel features, such as extended ntfs support and alternate tcp settings along with integrating and updating the kernel to current Linux revisions.
twistedumbrella said:
The source and commands may work but with using a Mac, even a source build results in loops, so I have to resolve that before saying it does the same thing.
After an interesting conversation, the mpdecision idea is pointless. I bought into the belief that it might be interesting to test an alternative, but the shield thermal control has been extremely well-designed.
The primary focus will be simply unlocking additional kernel features, such as extended ntfs support and alternate tcp settings along with integrating and updating the kernel to current Linux revisions.
Click to expand...
Click to collapse
Any word on what's the status here? Why does the kernel source require the full source anyways?
I'm just looking to be able to build the vanilla kernel with no hacks, I just want to compile extra modules for the kernel where I need them
vostok4 said:
Any word on what's the status here? Why does the kernel source require the full source anyways?
I'm just looking to be able to build the vanilla kernel with no hacks, I just want to compile extra modules for the kernel where I need them
Click to expand...
Click to collapse
I had a recent realization after working with the Note 4 that should allow me to build the stuff needed to compile kernels without the source. I just have to verify I can make it a distributable file and we should be good.
LinuxonAndroid is an on going project to bring a range of Linux distrobutions to Android devices, as the project has developed the team has grown and clear parts of the project have developed.
This thread has been created to handle development of the app itself, other parts of the project (Linux images, bootscripts etc) will have there own threads to talk about these sections and avoid confusions as the old thread has grown to 200+ pages.
XDA:DevDB Information
Complete Linux Installer, App for all devices (see above for details)
Contributors
zacthespack
Version Information
Status: Stable
Created 2014-06-07
Last Updated 2014-06-07
Reserved
Reserved
Could be interesting
Gesendet von meinem SGP321 mit Tapatalk
Yay, reorganized forums
droid bionic
can this work with a linux distro and the bionic hdmi port... Now cm11 has a working hdmi port it can be like webtop.
Casey Walt said:
can this work with a linux distro and the bionic hdmi port... Now cm11 has a working hdmi port it can be like webtop.
Click to expand...
Click to collapse
I'm not sure about the bionic hdmi port, as I haven't played with one of those yet, but this will allow you to load a linux distro with very nearly 100% functionality, the only real limits to the linux functionality are from not being able to compiler new drivers into the kernel that's stored by android, and the potential lack of some packages/functions in the ARM versions of some linux distributions.
One thing to be aware of, however, since you mentioned CM11, is that there is a glitch caused in the current version of the Complete Linux Installer app by CM11 ROMs which causes you to need to either manually input one command line to start the bootloader script, or set up a widget on your device to do that for you (sorry, it's a CyanogenMod quirk. We're working on it, but so far it's hard to track down since only CM seems to cause it).
robherc said:
I'm not sure about the bionic hdmi port, as I haven't played with one of those yet, but this will allow you to load a linux distro with very nearly 100% functionality, the only real limits to the linux functionality are from not being able to compiler new drivers into the kernel that's stored by android, and the potential lack of some packages/functions in the ARM versions of some linux distributions.
One thing to be aware of, however, since you mentioned CM11, is that there is a glitch caused in the current version of the Complete Linux Installer app by CM11 ROMs which causes you to need to either manually input one command line to start the bootloader script, or set up a widget on your device to do that for you (sorry, it's a CyanogenMod quirk. We're working on it, but so far it's hard to track down since only CM seems to cause it).
Click to expand...
Click to collapse
Im at school so I can't test it but I'll try and report back...hope it works