[Scummvm-devel] Android port

[Max Horn]

(I really don't like HTML mail, it makes proper quoting a pain unless you also reply with HTML mail, or you manually go and extract the plain text version, if any, from the email... *sigh*


Am 22.04.2010 um 07:36 schrieb Angus Lees:

> On Wed, Apr 21, 2010 at 23:44, Max Horn <fingolfin at scummvm.org> wrote:
> 
> > Hi Gus, hi team,
> >
> > thanks for your updated Android patch. Did you already see my last comments
> > on your patch? (For reference, I am talking about patch #2603856 <
> > https://sourceforge.net/tracker/?func=detail&aid=2603856&group_id=37116&atid=418822
> > >.)
> >
> 
> Just read your reply now.
> 
> 
> > From my point of view, with just very little bit of work (as detailed in my
> > comment on that tracker item) we could merge your port now -- at least in a
> > preliminary form, i.e., with the changes in gui/ not committed directly, but
> > only in the form of a patch file in backends/platforms/android. We could
> > then together work on resolving that last bit from inside the directory.
> > This is not 100% perfect, but 98%, as it would still avoid most of the
> > burden of porting your patches to each new version.
> >
> 
> This works for me.  How do you want me to submit such a patch?

The "small" patch I was talking about would go into backends/platforms/android/; and then you'd make yet another big patch, as before, just without the gui changes with the new "small" patch embedded just like the other new files.

And then submit that via the existing patch tracker item. :)


> I'll start another thread to discuss the theme .zip changes.

Still looking forward to that :)

> 
> > All in all, the port is IMO already in a better shape than some of our
> > existing ports *g*.
> >
> 
> The big problem with the port is that it uses a bunch of Android-internal
> functions - and the resulting ABI changes cause it to break across Android
> major releases.  I'm slowly removing these as the Android guys expose more
> things through legitimate APIs, but there will be a fair amount of code
> churn until then.  Unfortunately, many of these changes will probably
> involve switching from private C++ to public Java functions, which are
> typically 10x slower.


Can't be helped I guess... :/.

My impression is that the Android market is quite fragmented. Tons of phones are still being sold with Android 1.6 or even just 1.5, and no (official) way to upgrade them in sight, and there are also still quite some 2.0 phones out there... That sounds to me as if it was quite difficult to develop software which is really available on all Android phones. Nasty.
I wonder whether those changes you have to make mean that future versions of your port will only work on 2.x but not on 1.x?

Cheers,
Max