PPCGeeks
Page 1 of 2 1 2
Show 40 post(s) from this thread on one page

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.


All times are GMT -4. The time now is 11:17 AM.
Page 1 of 2 1 2
Show 40 post(s) from this thread on one page

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


Content Relevant URLs by vBSEO 3.6.0