PPCGeeks

PPCGeeks (http://forum.ppcgeeks.com/index.php)
-   Android On TP2 (http://forum.ppcgeeks.com/forumdisplay.php?f=179)
-   -   Alternatives to current development (http://forum.ppcgeeks.com/showthread.php?t=143427)

AmeiseMike 05-04-2011 08:05 PM
Alternatives to current development
 
Since it appears that the delays in having a fully functional Android build is that the drivers do not exist for the Linux kernel, and therefore equivalent drivers must be implemented, why not bypass this requirement altogether?

One could theoretically implement a POSIX wrapping layer on top of the CE Kernel, with a wrapper for Linux commands as well. The vast majority are either implemented mostly (WinSock vs POSIX Sockets, for instance), or would be trivial (pthreads versus Windows threads). If one can make the CE Kernel respond to POSIX and Linux API calls in a proper manner, one could theoretically run Android on top of the Windows CE Kernel. This would let you use the drivers are are extant for the system already. All that would then need to be implemented are the intermediate JNI layers within Android. You would also need to implement a means by which to execute ELF binaries.

This would be a large task, certainly, but if it is done, it means that practically any Windows CE device could have a full Android build ported.

You would lose ext2/4 support, though.

Just my 2 cents. You could always do the reverse and write a driver abstraction layer to handle CE drivers within Linux, but that may actually be more difficult.

Edit: This appears to have posted itself in the wrong forum - can someone please move it to the Android subforum of TP2?

gTen 05-05-2011 12:53 AM
Re: Alternatives to current development
 
Moved

arrrghhh 05-05-2011 01:19 AM
Re: Alternatives to current development
 
Running Android on a CE kernel... Just seems wrong.

What is really left that would benefit throwing away everything that's been done thus far and basically starting over on a complete rewrite that sounds bad even on paper... who knows how it would actually work, if at all.

highlandsun 05-05-2011 01:25 AM
The idea is totally ludicrous. Android doesn't run on a generic POSIX layer, it has a number of custom kernel drivers. Figuring out how to shoehorn them into CE would be a bear, even if you had CE kernel source.

It would be an utter waste of time. Look at how well Cygwin emulates POSIX on desktop windows (it's a dog). CE is even more lobotomized. Ridiculous.

Sent from my TP2 using Tapatalk

AmeiseMike 05-05-2011 01:56 AM
Re: Alternatives to current development
 
Quote:
Originally Posted by highlandsun (Post 2097416)
The idea is totally ludicrous. Android doesn't run on a generic POSIX layer, it has a number of custom kernel drivers. Figuring out how to shoehorn them into CE would be a bear, even if you had CE kernel source.

It would be an utter waste of time. Look at how well Cygwin emulates POSIX on desktop windows (it's a dog). CE is even more lobotomized. Ridiculous.

Sent from my TP2 using Tapatalk
There are not -that- many custom drivers, and most of them, their Android-specific behavior would just need to be re-implemented - this does not -need- to be done at the kernel-level, especially if you are developing an interface between CE and Android. You would certainly need to rework the JNI level interfaces, though.

I see your point about Cygwin DLL performance - however, many of the POSIX commands that would be required would almost be basic wrappers... the majority of the thread commands have near-direct analogs with the Windows API, for instance.

vinceweis 05-05-2011 02:03 AM
Re: Alternatives to current development
 
Quote:
Originally Posted by AmeiseMike (Post 2097422)
There are not -that- many custom drivers, and most of them, their Android-specific behavior would just need to be re-implemented - this does not -need- to be done at the kernel-level, especially if you are developing an interface between CE and Android. You would certainly need to rework the JNI level interfaces, though.

I see your point about Cygwin DLL performance - however, many of the POSIX commands that would be required would almost be basic wrappers... the majority of the thread commands have near-direct analogs with the Windows API, for instance.
When you have a version that loads on my Tilt2, I will give it a try. In the mean time, asking others to execute your ideas won't make it happen. Give us a plausable example.

AmeiseMike 05-05-2011 02:11 PM
Re: Alternatives to current development
 
Quote:
Originally Posted by vinceweis (Post 2097423)
When you have a version that loads on my Tilt2, I will give it a try. In the mean time, asking others to execute your ideas won't make it happen. Give us a plausable example.
Well, something I just wrote up. Doesn't handle attributes, but this is something such as pthread_create (don't mind syntax errors, I didn't try to compile it or check it, just wrote it quickly):

Code:
typedef struct pthread
{
        HANDLE mThreadHandle;
} pthread_t;

int pthread_create(
        pthread_t * restrict thread,
        const pthread_attr_t * restrict attr,
        void * (*start_routine)(void *),
        void * restrict arg
)
{
        //ignore attr for now
        thread = malloc(sizeof(pthread_t));
        thread->mThreadHandle = CreateThread(
                NULL,        //security descriptor LPSECURITY_ATTRIBUTES
                0,        //stack size. 0 is default
                /*
                ** the below is kinda wonky, and won't work on x64 systems.
                ** All current ARM processors are 32-bit.
                ** The size of a DWORD (as Win32/64 defines as the return type)
                ** is the same as the size of a pointer (as POSIX
                ** has as the return type) on 32-bit architectures.
                */
                (LPTHREAD_START_ROUTINE)start_routine,
                arg,
                0,        //start immediately
                NULL        //ptr to thread ID
        );

        if (thread->mThreadHandle == NULL)
        {
                //process from GetLastError. Don't feel like doing right now.
                return EINVAL;
        }
        return 0;
}

highlandsun 05-05-2011 03:05 PM
Congratulations, you've duplicated one API, only a couple thousand more to go. If you implement one/day successfully, you might be done in 3-5 years. Hint: you won't average one/day.

Sent from my TP2 using Tapatalk

arrrghhh 05-05-2011 03:09 PM
Re: Alternatives to current development
 
lol, I was just going to ask does BT work? GPS? Prox sensor? Ambient light sensor? How about stylus detection?

AmeiseMike, you seem like a sharp guy... Why not help out with the community development? The devs have made great progress, and help is always appreciated. The more people writing code, in theory the more code that makes it into the kernel :p.

AmeiseMike 05-05-2011 03:32 PM
Re: Alternatives to current development
 
If you cannot duplicate a single basic interface per day, then you aren't very good at what you do. pthreads itself has already been ported to the Windows API in the past, as have several other APIs. To be fair, however, that is not an API, it is a single API procedure, though the other pthread functions would be trivial to implement as well.

As per the 3-year concept... how long have you been trying to port Android onto the TP2, so far? A successful wrapping of the Android system around CE would allow any WinCE device to have 'droid, not just TP2.

arrrghhh - they don't need more programmers, they need people who can reverse engineer things. As per BT, GPS, Proximity, Ambient, etc, that would have been handled by the CE drivers. You'd need to implement the JNI wrappers in Android for them, though.

arrrghhh 05-05-2011 03:43 PM
Re: Alternatives to current development
 
Quote:
Originally Posted by AmeiseMike (Post 2097805)
If you cannot duplicate a single basic interface per day, then you aren't very good at what you do. pthreads itself has already been ported to the Windows API in the past, as have several other APIs. To be fair, however, that is not an API, it is a single API procedure, though the other pthread functions would be trivial to implement as well.

As per the 3-year concept... how long have you been trying to port Android onto the TP2, so far? A successful wrapping of the Android system around CE would allow any WinCE device to have 'droid, not just TP2.

arrrghhh - they don't need more programmers, they need people who can reverse engineer things. As per BT, GPS, Proximity, Ambient, etc, that would have been handled by the CE drivers. You'd need to implement the JNI wrappers in Android for them, though.
I know, I was teasing.

Indeed, people who are skilled at REing are always needed with this type of project - and hard to come by.

I guess I'll go back to what vinceweis said. Put up or shut up - either you help out, actually implement what you're talking about, or lurk and enjoy what the other developers are working very hard on. Your choice, I'm certainly not trying to discourage you from what you're doing - but from this angle and this stage in the game, it frankly seems counter-productive. If you think you can do it, then do it and prove us all wrong :D.

highlandsun 05-05-2011 08:15 PM
Re: Alternatives to current development
 
Quote:
Originally Posted by AmeiseMike (Post 2097805)
If you cannot duplicate a single basic interface per day, then you aren't very good at what you do. pthreads itself has already been ported to the Windows API in the past, as have several other APIs. To be fair, however, that is not an API, it is a single API procedure, though the other pthread functions would be trivial to implement as well.
It's trivial to port pthreads for the trivial cases. There are no guarantees that the Android userland is only a trivial threads consumer though. (I don't know if it uses more exotic features or not, haven't looked.) And yes, I know the POSIX APIs have been ported, I've done it myself at least twice. (E.g. OpenLDAP Source Repository - openldap.git/tree - libraries/libldap_r/ I'm also a MinGW/MSYS developer, and the guy who figured out how to implement signals in Win32 without all the crap the Cygwin guys do. Re: Ctrl-Break handler? - ReadList.com )

Quote:
As per the 3-year concept... how long have you been trying to port Android onto the TP2, so far? A successful wrapping of the Android system around CE would allow any WinCE device to have 'droid, not just TP2.
That's not a fair question, I've only started working on the TP2 port since middle of March. I'm pretty sure I could port most of Android to WinCE in a few months, but I have no desire to use Windows, and the parts that are undocumented would still be missing and require reverse-engineering. In the meantime, I've fixed quite a few years-outstanding bugs in just a matter of weeks here.

Quote:
arrrghhh - they don't need more programmers, they need people who can reverse engineer things. As per BT, GPS, Proximity, Ambient, etc, that would have been handled by the CE drivers. You'd need to implement the JNI wrappers in Android for them, though.
You'd need documentation for them, otherwise you'd still just be reverse-engineering, on an even more hostile environment. At least on the Android/Linux side of things, you have the majority of the source code available so you can see where the gaps are.

vinceweis 05-05-2011 08:59 PM
Re: Alternatives to current development
 
Quote:
Originally Posted by arrrghhh (Post 2097818)
I guess I'll go back to what vinceweis said. Put up or shut up -
I am more diplomatic or subtle, but it was exactly what I was thinking.:laughing6:

tiger2wander 05-06-2011 12:30 PM
Re: Alternatives to current development
 
I think AmeiseMike's idea is not so bad but it is so much hard to make it reality. The abstract layer is really flexible to make it usable most cross platform API like use .dll on Linux or .so on Windows but we can not implement all the JNI wrapper for each device, it is a very very big job and who know what's happen with them. Also Windows & Linux kernel is 2 kind of kernel and it all difference. AFAK, Android use Linux as a based but it also use emulator and native linux binary format, and many system process made to interactive directly with kernel signal and many other things like access /proc, /dev, /sys ... everything are related to Linux stuff, I think we can not handle it all.

There are simpler & easier way is use Ndiswrapper method to load WinCE's driver and call it's API, it is use in many Linux distro to reuse Windows's drivers such as closed source driver....
You all can read more about it in Wiki's page: NDISwrapper - Wikipedia, the free encyclopedia

Good luck!

oisact 05-07-2011 03:54 PM
Re: Alternatives to current development
 
I think the primary problem with this is that it would not bypass the very issues with WM6.5 that push me to Android on this phone. For example, sending and receiving texts. Would that just thunk calls down to MAPI under WM6.5, or is it possible to access lower-level radio functions and process all of that directly within Android? If it relies on MAPI then so much additional overhead will be incurred that there will be significant performance penalties. Further, the amount of RAM that WM can make available may not be enough for Android in the first place. I had this problem when I ported Quake 2 to Pocket PC. Some device models simply could not allocate enough contiguous memory for the game to run (20-30 MB). The hardware had enough physical memory, but because of OEM implementation issues it could not allocate such large blocks. These are the sorts of problems that would be encountered running one entire OS on top of another on hardware that is already resource-limited to begin with.


All times are GMT -4. The time now is 11:06 AM.

Powered by vBulletin® ©2000 - 2025, Jelsoft Enterprises Ltd.
©2012 - PPCGeeks.com


Content Relevant URLs by vBSEO 3.6.0