Coding under Android

Hi,

Well, I've been stymied trying to find 4-5" 4:3 LCD
touch panels (I did find a nice one at 5" but have yet
to chase down the manufacturer for availability).

Rather than wait, I am begrudgingly looking at a cheap ($50)
7" tablet to advance a bit further towards a real "beta".

Tablet runs Android. So, I can either figure out how
to root the thing (and then hope I can find docs on the
various bits of hardware inside) *or* build an emulation
system *under* Android to give me the environment I want.

The latter is less "run-time" efficient but may be a
better short-term bet to get further along with testing.

Also, I need a tablet-like device for another application
(though 7" is awfully large :< ).

So, how responsive is Android? How rich is the programming
model (flat address space? protection domains? VMM? etc.)?
What are the *gripes* about it? And, reasons for each
"point release" (i.e., are they fixing bugs or fixing
"missing features")?

Thx,
--don

On Aug 12, 2:50*pm, Don Y <nowh...@here.com> wrote:
> Hi,
>
> Well, I've been stymied trying to find 4-5" 4:3 LCD
> touch panels (I did find a nice one at 5" but have yet
> to chase down the manufacturer for availability).
>
> Rather than wait, I am begrudgingly looking at a cheap ($50)
> 7" tablet to advance a bit further towards a real "beta".
>
> Tablet runs Android. *So, I can either figure out how
> to root the thing (and then hope I can find docs on the
> various bits of hardware inside) *or* build an emulation
> system *under* Android to give me the environment I want.
>

Some are easier to root than others. Some even support rooted device
officially. Just ask them.

> The latter is less "run-time" efficient but may be a
> better short-term bet to get further along with testing.
>
> Also, I need a tablet-like device for another application
> (though 7" is awfully large *:< ).
>
> So, how responsive is Android? *How rich is the programming
> model (flat address space? *protection domains? *VMM? *etc.)?

It's Linux 2.6 kernel. Each process has linear virtual address space.

> What are the *gripes* about it? *

Some are difficult to root. Even so, we got something working on
unrooted droid via Android Debug Bridge over USB.

> And, reasons for each
> "point release" (i.e., are they fixing bugs or fixing
> "missing features")?

Android Development tool kits are different. But then, we go straight
with C anyway.

>
> Thx,
> --don

On 8/12/2011 3:02 PM, linnix wrote:
> On Aug 12, 2:50 pm, Don Y<nowh...@here.com> wrote:
>
>> Well, I've been stymied trying to find 4-5" 4:3 LCD
>> touch panels (I did find a nice one at 5" but have yet
>> to chase down the manufacturer for availability).
>>
>> Rather than wait, I am begrudgingly looking at a cheap ($50)
>> 7" tablet to advance a bit further towards a real "beta".
>>
>> Tablet runs Android. So, I can either figure out how
>> to root the thing (and then hope I can find docs on the
>> various bits of hardware inside) *or* build an emulation
>> system *under* Android to give me the environment I want.
>
> Some are easier to root than others. Some even support rooted device
> officially. Just ask them.

I'm looking at some of the no-name Chinese devices.
Can't afford to shell out 10 x hundreds of dollars
for "name brand" -- especially when all I *really*
want is the display+touch panel.

>> The latter is less "run-time" efficient but may be a
>> better short-term bet to get further along with testing.
>>
>> Also, I need a tablet-like device for another application
>> (though 7" is awfully large :< ).
>>
>> So, how responsive is Android? How rich is the programming
>> model (flat address space? protection domains? VMM? etc.)?
>
> It's Linux 2.6 kernel. Each process has linear virtual address space.

That's *all*? I thought android was something new from scratch...

>> What are the *gripes* about it?
>
> Some are difficult to root. Even so, we got something working on
> unrooted droid via Android Debug Bridge over USB.

But, that's a consequence of the particular implementation,
not Android itself. I want to know why I might want to
*avoid* an Android platform (assume it was "open")

>> And, reasons for each
>> "point release" (i.e., are they fixing bugs or fixing
>> "missing features")?
>
> Android Development tool kits are different. But then, we go straight
> with C anyway.

On Aug 13, 9:38*am, Don Y <nowh...@here.com> wrote:
> On 8/12/2011 3:02 PM, linnix wrote:
>
>
>
>
>
>
>
>
>
> > On Aug 12, 2:50 pm, Don Y<nowh...@here.com> *wrote:
>
> >> Well, I've been stymied trying to find 4-5" 4:3 LCD
> >> touch panels (I did find a nice one at 5" but have yet
> >> to chase down the manufacturer for availability).
>
> >> Rather than wait, I am begrudgingly looking at a cheap ($50)
> >> 7" tablet to advance a bit further towards a real "beta".
>
> >> Tablet runs Android. *So, I can either figure out how
> >> to root the thing (and then hope I can find docs on the
> >> various bits of hardware inside) *or* build an emulation
> >> system *under* Android to give me the environment I want.
>
> > Some are easier to root than others. *Some even support rooted device
> > officially. *Just ask them.
>
> I'm looking at some of the no-name Chinese devices.
> Can't afford to shell out 10 x hundreds of dollars
> for "name brand" -- especially when all I *really*
> want is the display+touch panel.
>
> >> The latter is less "run-time" efficient but may be a
> >> better short-term bet to get further along with testing.
>
> >> Also, I need a tablet-like device for another application
> >> (though 7" is awfully large *:< *).
>
> >> So, how responsive is Android? *How rich is the programming
> >> model (flat address space? *protection domains? *VMM? *etc.)?
>
> > It's Linux 2.6 kernel. *Each process has linear virtual address space..
>
> That's *all*? *I thought android was something new from scratch...

The user layers is totally different (but not new) from MS or X, but
the kernel is fairly standard.

>
> >> What are the *gripes* about it?
>
> > Some are difficult to root. *Even so, we got something working on
> > unrooted droid via Android Debug Bridge over USB.
>
> But, that's a consequence of the particular implementation,
> not Android itself. *I want to know why I might want to
> *avoid* an Android platform (assume it was "open")

Our reason to root it is to start a custom layer, and avoiding the
GUI. Why bother with G when we don't have much UI interactions.
However, your situation might be different.

On Aug 13, 11:38*am, Don Y <nowh...@here.com> wrote:
> On 8/12/2011 3:02 PM, linnix wrote:
>
>
> > On Aug 12, 2:50 pm, Don Y<nowh...@here.com> *wrote:
>
> >> Well, I've been stymied trying to find 4-5" 4:3 LCD
> >> touch panels (I did find a nice one at 5" but have yet
> >> to chase down the manufacturer for availability).
>
> >> Rather than wait, I am begrudgingly looking at a cheap ($50)
> >> 7" tablet to advance a bit further towards a real "beta".
>
> >> Tablet runs Android. *So, I can either figure out how
> >> to root the thing (and then hope I can find docs on the
> >> various bits of hardware inside) *or* build an emulation
> >> system *under* Android to give me the environment I want.
>
> > Some are easier to root than others. *Some even support rooted device
> > officially. *Just ask them.
>
> I'm looking at some of the no-name Chinese devices.
> Can't afford to shell out 10 x hundreds of dollars
> for "name brand" -- especially when all I *really*
> want is the display+touch panel.
>
> >> The latter is less "run-time" efficient but may be a
> >> better short-term bet to get further along with testing.
>
> >> Also, I need a tablet-like device for another application
> >> (though 7" is awfully large *:< *).
>
> >> So, how responsive is Android? *How rich is the programming
> >> model (flat address space? *protection domains? *VMM? *etc.)?
>
> > It's Linux 2.6 kernel. *Each process has linear virtual address space..
>
> That's *all*? *I thought android was something new from scratch...
>
> >> What are the *gripes* about it?
>
> > Some are difficult to root. *Even so, we got something working on
> > unrooted droid via Android Debug Bridge over USB.
>
> But, that's a consequence of the particular implementation,
> not Android itself. *I want to know why I might want to
> *avoid* an Android platform (assume it was "open")
>

Well... performance for certain applications are pretty lacking since
when programming an Android app you are limited to java and the
Android SDK. There does exist the NDK for more performance critical
applications... but it seems like a pain to use. For example, look at
the state of computer vision or even just imaging algorithms on
Android... pretty abysmal. Whereas you could get much better results
if you could just have the ability to code the thing in C.

Now that I think about it... if you have root maybe there is a way to
get some un-authorized native code running? I personally haven't tried
that.

With Android you are buying into the UI for the form factor. Getting
"support" for Android or the SoC specific kernel might be pretty
lacking as well (source is really fragmented, the last android or
kernel for that device, if any have existed before, might be really
old...) I would look at just putting on a regular GNU/Linux install on
the device if you want more control and performance and the end use
doesn't _have_ to be Android. Linaro.org might be of interest?


So what are you really using it for? You do know that the SDK and
tools already provide an emulator right?

Hi Bryan,

On 8/13/2011 5:12 PM, Bryan Buckley wrote:

[attributions elided]

>>> It's Linux 2.6 kernel. Each process has linear virtual address space..
>>
>> That's *all*? I thought android was something new from scratch...
>>
>>>> What are the *gripes* about it?
>>
>>> Some are difficult to root. Even so, we got something working on
>>> unrooted droid via Android Debug Bridge over USB.
>>
>> But, that's a consequence of the particular implementation,
>> not Android itself. I want to know why I might want to
>> *avoid* an Android platform (assume it was "open")
>
> Well... performance for certain applications are pretty lacking since
> when programming an Android app you are limited to java and the
> Android SDK. There does exist the NDK for more performance critical
> applications... but it seems like a pain to use. For example, look at
> the state of computer vision or even just imaging algorithms on
> Android... pretty abysmal. Whereas you could get much better results
> if you could just have the ability to code the thing in C.

You *can't*? If it's the "Linux 2.6 kernel", then are you saying
the kernel interfaces are *hidden*?

> Now that I think about it... if you have root maybe there is a way to
> get some un-authorized native code running? I personally haven't tried
> that.
>
> With Android you are buying into the UI for the form factor. Getting
> "support" for Android or the SoC specific kernel might be pretty
> lacking as well (source is really fragmented, the last android or
> kernel for that device, if any have existed before, might be really
> old...) I would look at just putting on a regular GNU/Linux install on
> the device if you want more control and performance and the end use
> doesn't _have_ to be Android. Linaro.org might be of interest?

I get nervous with the "chinese garage shops" (even if they
are multimillion dollar organizations!)

> So what are you really using it for? You do know that the SDK and
> tools already provide an emulator right?

Ideally, give me an X server and a means to export access to the
various devices on the box and I should be able to do what I want.
And/or a means of loading (smallish) applications/services into
RAM (so I can alter the device's characteristics)

On Sat, 13 Aug 2011 18:19:58 -0700, Don Y wrote:

>> Well... performance for certain applications are pretty lacking since
>> when programming an Android app you are limited to java and the Android
>> SDK. There does exist the NDK for more performance critical
>> applications... but it seems like a pain to use. For example, look at
>> the state of computer vision or even just imaging algorithms on
>> Android... pretty abysmal. Whereas you could get much better results if
>> you could just have the ability to code the thing in C.
>
> You *can't*? If it's the "Linux 2.6 kernel", then are you saying the
> kernel interfaces are *hidden*?

"Applications" are supposed to be written in Java, for portability and
security. Native development is intended for hardware vendors, not
third-party "app" developers. Access to the lower levels depends upon how
locked-down a particular model is. If the vendor is selling the hardware
at (or below) cost, with the intention of making their profit on services
and add-ons, they're going to try to keep you locked into their ecosystem.

On Aug 14, 12:01*pm, Nobody <nob...@nowhere.com> wrote:
> On Sat, 13 Aug 2011 18:19:58 -0700, Don Y wrote:
> >> Well... performance for certain applications are pretty lacking since
> >> when programming an Android app you are limited to java and the Android
> >> SDK. There does exist the NDK for more performance critical
> >> applications... but it seems like a pain to use. For example, look at
> >> the state of computer vision or even just imaging algorithms on
> >> Android... pretty abysmal. Whereas you could get much better results if
> >> you could just have the ability to code the thing in C.
>
> > You *can't*? *If it's the "Linux 2.6 kernel", then are you saying the
> > kernel interfaces are *hidden*?
>
> "Applications" are supposed to be written in Java, for portability and
> security. Native development is intended for hardware vendors, not
> third-party "app" developers. Access to the lower levels depends upon how
> locked-down a particular model is. If the vendor is selling the hardware
> at (or below) cost, with the intention of making their profit on services
> and add-ons, they're going to try to keep you locked into their ecosystem..

That seems to be the trend, everybody wants to sell you a TV set.
You are supposed to use the remote, no more.
Which can also be an opportunity to some of us, of course.

Dimiter

------------------------------------------------------
Dimiter Popoff Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tg...7600228621276/

On 8/14/2011 2:01 AM, Nobody wrote:
> On Sat, 13 Aug 2011 18:19:58 -0700, Don Y wrote:
>
>>> Well... performance for certain applications are pretty lacking since
>>> when programming an Android app you are limited to java and the Android
>>> SDK. There does exist the NDK for more performance critical
>>> applications... but it seems like a pain to use. For example, look at
>>> the state of computer vision or even just imaging algorithms on
>>> Android... pretty abysmal. Whereas you could get much better results if
>>> you could just have the ability to code the thing in C.
>>
>> You *can't*? If it's the "Linux 2.6 kernel", then are you saying the
>> kernel interfaces are *hidden*?
>
> "Applications" are supposed to be written in Java, for portability and
> security. Native development is intended for hardware vendors, not
> third-party "app" developers. Access to the lower levels depends upon how
> locked-down a particular model is. If the vendor is selling the hardware
> at (or below) cost, with the intention of making their profit on services
> and add-ons, they're going to try to keep you locked into their ecosystem.

I don't think that reasoning applies to the chinese knock-offs.
They just want to undercut the "mainstream" sellers.

Hi Dimiter,

On 8/14/2011 3:37 AM, dp wrote:

>> "Applications" are supposed to be written in Java, for portability and
>> security. Native development is intended for hardware vendors, not
>> third-party "app" developers. Access to the lower levels depends upon how
>> locked-down a particular model is. If the vendor is selling the hardware
>> at (or below) cost, with the intention of making their profit on services
>> and add-ons, they're going to try to keep you locked into their ecosystem..
>
> That seems to be the trend, everybody wants to sell you a TV set.
> You are supposed to use the remote, no more.
> Which can also be an opportunity to some of us, of course.

I think that's also what *customers* want. They don't want to
understand their products... just *use* them.

I'm embarassed at the number of "broken" items folks give me
(knowing I can either fix or salvage something from them).
After investing some time trying to figure out *what* is
broken, I'll approach the donor to *ask* what was wrong and
I'll get a dubious reply. If I press the issue, it often
resolves to: "Oh, we just wanted to get a newer model..."

<shrug> So, now they've handed off their responsibility for
figuring out what to do with the device to *me*! :-/

[P.S. I'll have updated pix for you, soon. Lots of progress,
here! Yay!]