Good news everyone, it looks like the android master branch as it's
available today can run on dream/ADP1 hardware.
In a nutshell, the instructions at
http://source.android.com/documentation/building-for-dream work. When
you're done, reboot into the bootloader and run fastboot -w flashall.
A bit of refinement to make life smoother:
-adb pull /system/etc/apns-conf.xml and stick it in
development/data/etc/apns-conf_sdk.xml
-tweak development/apps/SdkSetup/Android.mk to use LOCAL_MODULE_TAGS
:= eng development
-tweak development/apps/SdkSetup/AndroidManifest.xml to add the
WRITE_SETTINGS in addition to WRITE_SECURE_SETTINGS
The first step will give you APNs properly set up, so that you don't
have to input them manually.
The other two will configure your device to be provisioned, so that
home/dial and the keyguard work.
The state of things: GSM voice and data work. Wifi doesn't work. SD
card works. Camera works, though the preview and orientation look odd.
Audio playback works. I wouldn't bet much on bluetooth or GPS.
(disclaimer: I actually did it with a development device running an
engineering bootloader, and I started from a build of TC4-RC30 instead
of the actual ADP1 build, but it should be close enough).
ONCE AGAIN: ONCE YOU FLASH YOUR ADP1, YOU HAVE NO OFFICIAL WAY TO GET
IT BACK TO THE INITIAL BUILD THAT CAME WITH IT.
--
Jean-Baptiste M. "JBQ" Queru
Android Engineer, Google.
JBQ
JBQ
JBQ
JBQ
I have little visibility over the 1.0 aspects, sorry. You might be
able to get away with editing your local_manifest to fetch the master
revision f that repository, and they manually git checkout the 3
relevant repositories to an older point that's compatible with the
rest of 1.0, but I have never done that so I don't know whether it's
even actually possible.
JBQ
--
Aaron:
-I'll be passing this information around, so that it gets included in
either the documentation or in the source code itself, depending on
which is the most appropriate.
-Google today is still working with an internal repository and
internal tools. We're working hard to transition to the public
repository and tools, but we're not quite there yet. Other than a
delay of a few days (we're trying to reduce it as much as we possibly
can), differences between the internal repository and the public one
are in proprietary or vendor-specific areas that aren't part of the
Android Open-Source Project but are necessary to run on dream. Those
differences explain why Google can build fully functional system
images for dream from its internal repository but the rest of the
community can't do the same from the public repository. We're
obviously aware of the pain that this causes and we're trying to
resolve it.
JBQ
Cupcake is supposed to be backward-compatible with properly written
applications by the time it ships, and bleeding-edge builds are
usually pretty compatible.
JBQ
--
Once I get there it'll be easier to go poke other engineers to
investigate the other aspects.
I'll keep you posted when we reach some meaningful milestones.
JBQ