> Hi Andreas,

> I've submitted my skeleton, with the caveat that it's very bare.

> Beware that there's no actual kernel (I've put an empty file in its
> place). My next step is to get the real kernel sources in AOSP and to
> build my own kernel.

> I think the other urgent step is to get a proper BoardConfig.mk in
> there. You probably have something suitable.

> I'm not incredibly worried about recovery (yet). I guess I'm biased,
> since I only work on devices with unlocked bootloaders, so I'm used to
> relying solely on fastboot.

> JBQ

> On Wed, Aug 15, 2012 at 4:47 AM, Andreas Makris
> <andreas...@gmail.com <javascript:>> wrote:
> > Hey JBQ,

> > nice challenge you put up here :D
> > I am one of the guys maintaining Sony Devices on CM tree. So this device
> is
> > very common to me. OFC it is a powerful device, but it has some tricky
> stuff
> > in it.
> > For example the recovery is not this useable than a recovery on a Nexus
> > device, so we trigger the recovery boot from boot.img and not from
> > bootloader itself.
> > Some more special stuff is going on here, but all is possible to handle
> ;)

> > So start the skeleton, I am happy to help getting this up and running on
> > AOSP.

> > Best Regards
> > Andreas aka. Bin4ry

> > Am Dienstag, 14. August 2012 22:11:45 UTC+2 schrieb Jean-Baptiste Queru:

> >> TL;DR: For a long while this'll probably only be useful for low-level
> >> engineering, but won't be usable as a daily driver.

> >> In theory, AOSP is designed such that it should be possible to plug in
> >> the files related to additional hardware targets. In practice, that
> >> has never happened.

> >> The short-term goal is to investigate the difference between theory
> >> and practice, on a favorable real-world example, and to see whether
> >> the result is worth the effort. The long-term goal is to try to
> >> eliminate whatever hurdles we find, both the expected and the
> >> unexpected ones.

> >> I expect that we'll need at least a few iterations before that can
> >> become usable as a day-to-day phone, and it's unclear whether that'll
> >> ever happen. There's a reasonable chance that it could be useful for
> >> people working at a lower level, literally several layers below the UI
> >> and applications that everyone is familiar with. If you've seen the
> >> classic Android Architecture diagram, we're going to be in the kernel
> >> and just above it.

> >> I don't want to use the word "supported" because there's no way to
> >> agree on a single unambiguous definition.

> >> JBQ

> >> On Tue, Aug 14, 2012 at 12:43 PM, Artem Russakovskii
> >> <arch...@gmail.com> wrote:
> >> > Fantastic. So what's the high level goal here, in layman's terms?
> Does
> >> > the
> >> > future hold direct support in AOSP for building more than just Nexus
> >> > devices? Are you thinking of targeting only a certain subset of
> devices
> >> > (say, ones that satisfy a list of parameters - GSM, unlockable
> >> > bootloader,
> >> > etc)? What about the lack of proprietary drivers (though even the
> Nexus
> >> > phones have this problem, and they're supported by AOSP)?

> >> > On Tuesday, August 14, 2012 12:35:38 PM UTC-7, Jean-Baptiste Queru
> >> > wrote:

> >> >> I'm going to try an experiment.

> >> >> Over time, AOSP has added files related to various hardware targets.
> >> >> We started with just a few scripts on a web page (1.0), then we had
> a
> >> >> git project (Cupcake), then we released some of the exact source
> files
> >> >> that were used on retail flagship devices (Froyo), then distributed
> >> >> proprietary binaries (Gingerbread), then we were able to run on
> >> >> PandaBoard (Ice Cream Sandwich).

> >> >> For a new challenge, I'd like to try to go one step further, and to
> >> >> target some hardware beyond the usual categories. I've added a git
> >> >> project for the Sony LT26, i.e. Xperia S. This seems like a good
> >> >> target: it's a powerful current GSM device, with an unlockable
> >> >> bootloader, from a manufacturer that has always been very friendly
> to
> >> >> AOSP.

> >> >> That git project is currently empty. I'm open to suggestions about
> the
> >> >> best way to populate it. I think I'll start by putting together a
> >> >> skeleton set of makefiles, followed by a kernel. Contributions are
> >> >> strongly encouraged, and there should be more freedom than usual to
> >> >> submit experimental changes since that won't impact the devices that
> >> >> Google is most directly involved in.

> >> >> I don't know how far that'll go, and there are so many unknowns that
> >> >> the only way to know is to try it.

> >> >> As usual, please be very careful about handling any proprietary
> files,
> >> >> for Xperia S or any other device. Don't copy them, use them, or
> >> >> distribute them without an appropriate license. Obviously, don't
> >> >> upload them to AOSP if you don't own them. When in doubt, please ask
> >> >> ahead of time, it's easier to answer an email than to fix things in
> an
> >> >> emergency.

> >> >> JBQ

> >> >> --
> >> >> Jean-Baptiste M. "JBQ" Queru
> >> >> Technical Lead, Android Open Source Project, Google.

> >> >> Questions sent directly to me that have no reason for being private
> >> >> will likely get ignored or forwarded to a public forum with no
> further
> >> >> warning.

> >> > --
> >> > You received this message because you are subscribed to the "Android
> >> > Building" mailing list.
> >> > To post to this group, send email to android-...@googlegroups.com
> >> > To unsubscribe from this group, send email to
> >> > android-buildi...@googlegroups.com
> >> > For more options, visit this group at
> >> > http://groups.google.com/group/android-building?hl=en

> >> --
> >> Jean-Baptiste M. "JBQ" Queru
> >> Technical Lead, Android Open Source Project, Google.

> >> Questions sent directly to me that have no reason for being private
> >> will likely get ignored or forwarded to a public forum with no further
> >> warning.

> > --
> > You received this message because you are subscribed to the "Android
> > Building" mailing list.
> > To post to this group, send email to android-...@googlegroups.com<javascript:>
> > To unsubscribe from this group, send email to
> > android-buildi...@googlegroups.com <javascript:>
> > For more options, visit this group at
> > http://groups.google.com/group/android-building?hl=en

> --
> Jean-Baptiste M. "JBQ" Queru
> Technical Lead, Android Open Source Project, Google.

> Questions sent directly to me that have no reason for being private
> will likely get ignored or forwarded to a public forum with no further
> warning.