Re: [AD] Android port notes

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


One suggestion I want to make is to not use Android version numbers
but API levels. This will be less confusing for developers.

On 11 March 2012 11:57, Thomas Fjellstrom <tfjellstrom@xxxxxxxxxx> wrote:
> Ok, for those interested in the port, some notes.
>
> Some things should be kept in mind due to the nature of the android platform.
>
> The latest SDK should always be used if at all possible. The latest platform
> version should be targeted (with minSDK targeting something like 1.6 or 2.2?).
> OpenGL ES support should likewise be treated as supporting the abolute latest
> in the default config of allegro. Meaning, a generic setup of an allegro
> android project should be able to be compiled to work on versions from 1.6
> (2.2?) through 4.0. ****
>
> I intend to build a table of the various supported android device profiles,
> including cpu type, instruction set version, and instruction set extensions,
> to help lay out a proper set of compile time switches.
>
> **** that's given that the platform works the way I assume it does, I don't
> know for sure exactly how the store treats different cpu variants yet. if you
> can't make a large monolithic multi arch apk, then well it may not make much
> sense at all to allow the use of say, GLES2, on a compile that can work on 1.6
> devices, and most of them likely won't support GLES2. This needs some thought.
>
> To trentg, that WANT_ANDROID_4 option is very mis-named. Someone more familiar
> with Android development will immediately assume Android ICS (aka 4.0) when
> reading that. And we /really/ shouldn't be making that /just/ a compile time
> option. I have nothing against having compile time options that cut out a lot
> of compatability code paths, but by default I think the config should be to
> leave most of them in, so as few apk's need to be built as possible for a
> given app (last I heard the android store can be silly about multiple apk
> package versions).
>
> Note: I'm quite tired, so I may have misunderstood some of the changes
> you/trentg made, or completely mis-brained everything I wrote above. But
> that's just some of the stuff I've been thinking about, and it should be kept
> in mind.
>
> --
> Thomas Fjellstrom
> tfjellstrom@xxxxxxxxxx
>
> ------------------------------------------------------------------------------
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> --
> https://lists.sourceforge.net/lists/listinfo/alleg-developers



-- 
thedmd, Michał Cichoń
Artifex Mundi
michcic@xxxxxxxxxx
http://www.artifexmundi.com




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/