Monday, November 10, 2008

Porting Android, Phase 4: Done

Sean McNeil is still actively porting the Android to the Neo FreeRunner. Today there were new images. For a getting started manual, look in my previous blogpost.

In short

  1. Make compatible Linux kernel (done)
  2. Replace ARMv5 specific code (done)
  3. Create images (done)
  4. Replace hardware specific code (done)
    - SMS (done)
    - Calling (done)
    - Wifi (in progress)
    - GPS (done)
    - Bluetooth (done)
    -
    Accelerators (done)
  5. Adding additional software, like on-screen keyboard
In depth
Most of the devices are already working in the first image that Sean McNeil has posted. Though Bluetooth wasn't fully patched in the images, because Sean forgot to apply one patch. So it didn't work. With the new images (That you can find on the same location as the previous), Bluetooth works magically. In the new image is Wifi still not working in all situations and can be unstable.

The biggest improvement in the new image is the screen redraws. Sometimes you could see the redraws, for example when you opened the 'Shutdown menu'. That has now been solved by implementing 'Page flipping' for the Glamo.

What's next?
By looking at the porting strategy above, you will see that we just need one thing. W'e need a working on-screen keyboard, before we can fully use the Android. To bad for us, Sean will not start to make something like that. There are 2 reasons for that.

Firstly Google has announced they would make an input device management system with an onscreen keyboard in the first quarter of 2009. Secondly it isn't that easy for making a onscreen keyboard. At the moment there are no java bindings for letting a program insert keystrokes to other programs (Due to security constraints). So if you make an onscreen keyboard, you would have to change every program to work with your onscreen keyboard.

So what's next?
There is still plenty to do:
  • Optimizing the code and all the patches. (And sending upstream)
  • Making a way to accept incoming calls. (On the HTC G1, there is a accept call button)
  • Let suspend work reliable

14 reacties:

yoyo said...

I'm very happy with new android. Tully a magnificent work. Sean You rock!

Tobias said...

This second images are great, but I wouldn't consider the GSM part as done, because it doesn't accept the sim PIN yet. If the sim is protected android asks for the PIN, but always says it's incorrect :(. Without PIN it works ok.

Vasili Sviridov said...

does suspend work in this version?

René T said...

There is already a softkeyboard for android, http://groups.google.com/group/android-developers/browse_thread/thread/957b7b8214769ffb/d7af43ae25e90353?lnk=raot. It would require some android-hackin to make it work in every app, though.

Vasili Sviridov said...

Not sure about suspend, managed to get it to the state where I had to unplug the battery. WiFi doesn't work at all. Also didn't figure out to accept the call. Making calls seems to work all right.

Vasili Sviridov said...

Starts up and runs w/o SIM card. Shows the fact on the lock screen and via icon on the top panel.

Chris Bainbridge said...

You don't need to post directly from one application to another for a virtual keyboard - you just need to have some mechanism for forwarding fake key presses through the kernel (similar to acpi_fakekey). User mode applications will never know the difference between fake and real key press events.

Vasili Sviridov said...

> User mode applications will never know the difference between fake and real key press events.

How do you separate which application can issue fake keypresses and which cant? Still requires tighter integration into android code compared to a regular app.

I can already see an app that would blurt obscenities at random intervals for the fun of it :)

Vasili Sviridov said...
This post has been removed by the author.
Chris Bainbridge said...

How? Standard file permissions. You have a "keyboard" group, and keyboard processes are part of that group, and the fake key device on /dev/input/x is writable only by that group. The keyboard would be a native executable, and all events would be handled in the kernel - it wouldn't require any integration with Android code on the event handling side. On the keyboard side, you'd need to use Skia to pop up a keyboard on screen, take the text, and close. But Android should already have some mechanism for this - there must be many Android phones which don't have full qwerty keyboards!

René T said...

bullshit

The key part of a virtual keyboard isn't "fire a key press", it's "pop up when needed, draw yourself to the screen, interact with the user and finally fire a key event". The whole key-press-emulation part is propably 1/10th of the app...

The hard constraints are user interaction and drawing. There is no other way than an Android app with UI toolkit support for the popup/input-routing part... A "native" app will fail as it would require patches from the native input layer to the native drawing layer, with the drawing layer being the hard part.

I've never said that the soft keyboard would be usefull without patches to the Android UI core. But a lot of the work (UI, Interaction, ...) is already done and thus might act as a starting point for input method patches/testing.

Chris Bainbridge said...

Surely you can detect when the user presses some special key (or keys combination), in order to know when to pop up the keyboard app, then use either skia or the framebuffer to draw a keyboard and get the input, then restore the previous image and process the key events. The drawing layer is just skia running on a framebuffer - surely that's so hard to get output onto? Skia is open source, and the framebuffer is a standard bitmapped device.

oy said...
This post has been removed by a blog administrator.
wow gold said...

Weekends to peopleig2tmean that they can have a two-day wowgold4europe good rest. For example, people gameusdcan go out to enjoy themselves or get meinwowgoldtogether with relatives and friends to talk with each storeingameother or watch interesting video tapes with the speebiewhole family.
Everyone spends agamegoldweekends in his ownmmoflyway. Within two days,some people can relax themselves by listening to music, reading novels,or watchingogeworld films. Others perhaps are more active by playing basketball,wimming ormmorpgvipdancing. Different people have different gamesavorrelaxations.
I often spend weekends withoggsalemy family or my friends. Sometimes my parents take me on a visit to their old friends. Sometimesgamersell I go to the library to study or borrow some books tommovirtexgain much knowledge. I also go to see various exhibition to broadenrpg tradermy vision. An excursion to seashore or mountain resorts is my favorite way of spending weekends. Weekends are always enjoyable for me.
igxe swagvaultoforu wowgold-usaignmax wowgoldlivebrogame thsaleGoldRockUbrogameswagvaultgoldsoonoforuigxethsale