I want to make sure that I have this right because each time I don't,
I end up recompiling the whole thing, which takes an hour. Can others
please look this over and make sure that I'm not leaving out any
steps, and that I have the right ideas? I would expect to find this at
the end of the "Get source" page, but maybe I'm misunderstanding how
this all works.
From what I understand, to make (and test) changes to the Android
code, the process is this:
1. Download the source per the instructions here: http://source.android.com/download 2. Make changes to the source
2. cd ~/mydroid
3. source build/envsetup.sh
4. make -j4 sdk (with 4 being twice the number of processors in my
machine)
5. /out/host/linux-x86/bin/emulator (test the changes)
6. Make more changes
7. Recompile as necessary with something like: mmm packages/apps/Email
or mmm framework/base/core/res
8. Sync the changes into the emulator, or simply restart it. To sync
it: adb remount; adb shell stop; adb sync; adb shell start
9. Debug using ddms or the ddms perspective in Eclipse
10. Repeat steps 6-9
Questions:
1. Somewhere, I've left out the "lunch 1" command that does
something....but where, and is it important?
2. I'm a little confused why anybody would run make without running
make sdk. Seems like you'd almost always want to make the sdk, but I'm
probably missing something here.
3. Once this is all done, the home button won't work unless a change
is made to include SdkSetup. Therefore the 0th step should be to make
the change mentioned here:
http://groups.google.com/group/android-porting/browse_thread/thread/2... 4. Once this is all done, an emulator should have been created that
has an SD card, allows GPS emulation, and pretty much all-around
works. Correct?
Other facts:
1. AVDs aren't necessary because "the build system configures the
locally built emulator to automatically pick the locally built system
image without going through any AVD." (source: JBQ at
http://groups.google.com/group/android-platform/t/293945cb8dcf1151)
> Questions:
> 1. Somewhere, I've left out the "lunch 1" command that does
> something....but where, and is it important?
I don't use it , but I guess it set the environment so it won't
complaing about avds
> 2. I'm a little confused why anybody would run make without running
> make sdk. Seems like you'd almost always want to make the sdk, but I'm
> probably missing something here.
You want to develop for platform, not to build the sdk
> 3. Once this is all done, the home button won't work unless a change
> is made to include SdkSetup. Therefore the 0th step should be to make
> the change mentioned here:http://groups.google.com/group/android-porting/browse_thread/thread/2...
> 4. Once this is all done, an emulator should have been created that
> has an SD card, allows GPS emulation, and pretty much all-around
> works. Correct?
> Other facts:
> 1. AVDs aren't necessary because "the build system configures the
> locally built emulator to automatically pick the locally built system
> image without going through any AVD." (source: JBQ athttp://groups.google.com/group/android-platform/t/293945cb8dcf1151)
"make sdk" is typically used to build the SDK to be used as if it was
an SDK downloaded from d.android.com - that's not normally used for
platform development.
my workflow:
(download source)
source build/envsetup.sh
lunch generic-eng #generic-eng is the default value
(modify files, commit them)
make -j8 #I have a quad-core
emulator&
(whatever makes sense from this point, local changes, incremental
builds, adb sync...)
Yeah, the SdkSetup part is screwed up, that's a good local change to
make if you want your "device" to be provisioned (and use the home
key, have a lock screen, and a number of other things).
The SD card may or may not work - this has been a hit-and-miss affair.
I haven't tested it recently on an open-source emulator.
On Wed, Aug 12, 2009 at 4:23 PM, Mike Lissner<mjliss...@gmail.com> wrote:
> I want to make sure that I have this right because each time I don't,
> I end up recompiling the whole thing, which takes an hour. Can others
> please look this over and make sure that I'm not leaving out any
> steps, and that I have the right ideas? I would expect to find this at
> the end of the "Get source" page, but maybe I'm misunderstanding how
> this all works.
> From what I understand, to make (and test) changes to the Android
> code, the process is this:
> 1. Download the source per the instructions here: http://source.android.com/download > 2. Make changes to the source
> 2. cd ~/mydroid
> 3. source build/envsetup.sh
> 4. make -j4 sdk (with 4 being twice the number of processors in my
> machine)
> 5. /out/host/linux-x86/bin/emulator (test the changes)
> 6. Make more changes
> 7. Recompile as necessary with something like: mmm packages/apps/Email
> or mmm framework/base/core/res
> 8. Sync the changes into the emulator, or simply restart it. To sync
> it: adb remount; adb shell stop; adb sync; adb shell start
> 9. Debug using ddms or the ddms perspective in Eclipse
> 10. Repeat steps 6-9
> Questions:
> 1. Somewhere, I've left out the "lunch 1" command that does
> something....but where, and is it important?
> 2. I'm a little confused why anybody would run make without running
> make sdk. Seems like you'd almost always want to make the sdk, but I'm
> probably missing something here.
> 3. Once this is all done, the home button won't work unless a change
> is made to include SdkSetup. Therefore the 0th step should be to make
> the change mentioned here:
> http://groups.google.com/group/android-porting/browse_thread/thread/2... > 4. Once this is all done, an emulator should have been created that
> has an SD card, allows GPS emulation, and pretty much all-around
> works. Correct?
> Other facts:
> 1. AVDs aren't necessary because "the build system configures the
> locally built emulator to automatically pick the locally built system
> image without going through any AVD." (source: JBQ at
> http://groups.google.com/group/android-platform/t/293945cb8dcf1151)
My impressions, as a mostly-outsider to this discussion....
On Wed, Aug 12, 2009 at 4:23 PM, Mike Lissner<mjliss...@gmail.com> wrote:
> Questions: > 1. Somewhere, I've left out the "lunch 1" command that does > something....but where, and is it important?
'lunch' is a shell command provided by the env_setup.sh configuration step. It allows you to select among various products and build flavors (eng, user, etc), and configures your environment appropriately. Within Google's Android team, for example, this is used all the time to switch between e.g. doing dream (G1 type hardware) versus sapphire (Magic type hardware) builds, between T-Mobile US vs Vodafone etc product bundles, etc.
If you just type 'lunch' with no argument, you should be presented with a pick list of the most common / relevant options.
> 2. I'm a little confused why anybody would run make without running > make sdk. Seems like you'd almost always want to make the sdk, but I'm > probably missing something here.
I think the opposite: nobody working with the main source base should ever run 'make sdk' unless they're engaged in editing and publishing a new formal SDK. When you're working within the platform sources themselves, the distinction between public and private APIs is not particularly relevant. The primary 'make' build will enforce the current, existing API so that you don't inadvertently break anything, and that's all you need to worry about.
(Note that typically nobody at Google runs 'make sdk' unless they are part of the group putting together a new SDK package.)
Aha, yes, for the AOSP situation you're probably right that this is Step 0. jbq or someone, can you confirm?
> 4. Once this is all done, an emulator should have been created that > has an SD card, allows GPS emulation, and pretty much all-around > works. Correct?
Hrm. This does not create an sdcard image; you have to create one by hand. However, the emulator takes a command line argument "-sdcard" that lets you specify the image by path, no AVDs involved. AVDs are not part of the daily (or weekly or monthly or...) life of the Android framework engineers at Google.
On Wed, Aug 12, 2009 at 4:23 PM, Mike Lissner <mjliss...@gmail.com> wrote: > 7. Recompile as necessary with something like: mmm packages/apps/Email > or mmm framework/base/core/res
If you are changing the framework itself, my preference is "mmm framework/base/core/res snod" and then you can re-run the emulator with the new system image created by snod.
Actually, for most of my work on the framework I just do:
make framework-res framework services snod emulator
This ensures the framework resources, code, and service code are all build and stuffed into a new system image.
Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them.
I can confirm that the step 0 as mentioned used to be the right one -
it might still work but I'm not sure.
As for the sdcard, once you've built you should be able to create an
SD image with mksdcard (run it with no arguments for the list of
arguments), and use the resulting image with the -sdcard emulator
argument that Chris mentioned.
On Wed, Aug 12, 2009 at 4:35 PM, Christopher Tate<ct...@google.com> wrote:
> My impressions, as a mostly-outsider to this discussion....
> On Wed, Aug 12, 2009 at 4:23 PM, Mike Lissner<mjliss...@gmail.com> wrote:
>> Questions:
>> 1. Somewhere, I've left out the "lunch 1" command that does
>> something....but where, and is it important?
> 'lunch' is a shell command provided by the env_setup.sh configuration
> step. It allows you to select among various products and build
> flavors (eng, user, etc), and configures your environment
> appropriately. Within Google's Android team, for example, this is
> used all the time to switch between e.g. doing dream (G1 type
> hardware) versus sapphire (Magic type hardware) builds, between
> T-Mobile US vs Vodafone etc product bundles, etc.
> If you just type 'lunch' with no argument, you should be presented
> with a pick list of the most common / relevant options.
>> 2. I'm a little confused why anybody would run make without running
>> make sdk. Seems like you'd almost always want to make the sdk, but I'm
>> probably missing something here.
> I think the opposite: nobody working with the main source base should
> ever run 'make sdk' unless they're engaged in editing and publishing a
> new formal SDK. When you're working within the platform sources
> themselves, the distinction between public and private APIs is not
> particularly relevant. The primary 'make' build will enforce the
> current, existing API so that you don't inadvertently break anything,
> and that's all you need to worry about.
> (Note that typically nobody at Google runs 'make sdk' unless they are
> part of the group putting together a new SDK package.)
> Aha, yes, for the AOSP situation you're probably right that this is
> Step 0. jbq or someone, can you confirm?
>> 4. Once this is all done, an emulator should have been created that
>> has an SD card, allows GPS emulation, and pretty much all-around
>> works. Correct?
> Hrm. This does not create an sdcard image; you have to create one by
> hand. However, the emulator takes a command line argument "-sdcard"
> that lets you specify the image by path, no AVDs involved. AVDs are
> not part of the daily (or weekly or monthly or...) life of the Android
> framework engineers at Google.
Thank you everybody for the detailed answers, since I know your time
is valuable. This should get me off to a better start with my
modifications to the code. I am quite pleased to get so many answers
directly from the horse's mouth (so to speak)!
The one question that I have now is why this process isn't on the
android development site? It took me a good deal of research to figure
out the above post, and it seems like the kind of hurdle that all
developers are going to have to jump right when they are starting to
get their feet wet.
Thanks again,
Mike
On Aug 12, 5:18 pm, Jean-Baptiste Queru <j...@android.com> wrote:
> I can confirm that the step 0 as mentioned used to be the right one -
> it might still work but I'm not sure.
> As for the sdcard, once you've built you should be able to create an
> SD image with mksdcard (run it with no arguments for the list of
> arguments), and use the resulting image with the -sdcard emulator
> argument that Chris mentioned.
> JBQ
> On Wed, Aug 12, 2009 at 4:35 PM, Christopher Tate<ct...@google.com> wrote:
> > My impressions, as a mostly-outsider to this discussion....
> > On Wed, Aug 12, 2009 at 4:23 PM, Mike Lissner<mjliss...@gmail.com> wrote:
> >> Questions:
> >> 1. Somewhere, I've left out the "lunch 1" command that does
> >> something....but where, and is it important?
> > 'lunch' is a shell command provided by the env_setup.sh configuration
> > step. It allows you to select among various products and build
> > flavors (eng, user, etc), and configures your environment
> > appropriately. Within Google's Android team, for example, this is
> > used all the time to switch between e.g. doing dream (G1 type
> > hardware) versus sapphire (Magic type hardware) builds, between
> > T-Mobile US vs Vodafone etc product bundles, etc.
> > If you just type 'lunch' with no argument, you should be presented
> > with a pick list of the most common / relevant options.
> >> 2. I'm a little confused why anybody would run make without running
> >> make sdk. Seems like you'd almost always want to make the sdk, but I'm
> >> probably missing something here.
> > I think the opposite: nobody working with the main source base should
> > ever run 'make sdk' unless they're engaged in editing and publishing a
> > new formal SDK. When you're working within the platform sources
> > themselves, the distinction between public and private APIs is not
> > particularly relevant. The primary 'make' build will enforce the
> > current, existing API so that you don't inadvertently break anything,
> > and that's all you need to worry about.
> > (Note that typically nobody at Google runs 'make sdk' unless they are
> > part of the group putting together a new SDK package.)
> > Aha, yes, for the AOSP situation you're probably right that this is
> > Step 0. jbq or someone, can you confirm?
> >> 4. Once this is all done, an emulator should have been created that
> >> has an SD card, allows GPS emulation, and pretty much all-around
> >> works. Correct?
> > Hrm. This does not create an sdcard image; you have to create one by
> > hand. However, the emulator takes a command line argument "-sdcard"
> > that lets you specify the image by path, no AVDs involved. AVDs are
> > not part of the daily (or weekly or monthly or...) life of the Android
> > framework engineers at 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.
I have a big item on my "todo" list to add a page on
source.android.com to host that information, because it's indeed
missing, and it's an unnecessarily steep part of the learning curve.
On Thu, Aug 13, 2009 at 11:46 AM, Mike Lissner<mjliss...@gmail.com> wrote:
> Thank you everybody for the detailed answers, since I know your time
> is valuable. This should get me off to a better start with my
> modifications to the code. I am quite pleased to get so many answers
> directly from the horse's mouth (so to speak)!
> The one question that I have now is why this process isn't on the
> android development site? It took me a good deal of research to figure
> out the above post, and it seems like the kind of hurdle that all
> developers are going to have to jump right when they are starting to
> get their feet wet.
> Thanks again,
> Mike
> On Aug 12, 5:18 pm, Jean-Baptiste Queru <j...@android.com> wrote:
>> I can confirm that the step 0 as mentioned used to be the right one -
>> it might still work but I'm not sure.
>> As for the sdcard, once you've built you should be able to create an
>> SD image with mksdcard (run it with no arguments for the list of
>> arguments), and use the resulting image with the -sdcard emulator
>> argument that Chris mentioned.
>> JBQ
>> On Wed, Aug 12, 2009 at 4:35 PM, Christopher Tate<ct...@google.com> wrote:
>> > My impressions, as a mostly-outsider to this discussion....
>> > On Wed, Aug 12, 2009 at 4:23 PM, Mike Lissner<mjliss...@gmail.com> wrote:
>> >> Questions:
>> >> 1. Somewhere, I've left out the "lunch 1" command that does
>> >> something....but where, and is it important?
>> > 'lunch' is a shell command provided by the env_setup.sh configuration
>> > step. It allows you to select among various products and build
>> > flavors (eng, user, etc), and configures your environment
>> > appropriately. Within Google's Android team, for example, this is
>> > used all the time to switch between e.g. doing dream (G1 type
>> > hardware) versus sapphire (Magic type hardware) builds, between
>> > T-Mobile US vs Vodafone etc product bundles, etc.
>> > If you just type 'lunch' with no argument, you should be presented
>> > with a pick list of the most common / relevant options.
>> >> 2. I'm a little confused why anybody would run make without running
>> >> make sdk. Seems like you'd almost always want to make the sdk, but I'm
>> >> probably missing something here.
>> > I think the opposite: nobody working with the main source base should
>> > ever run 'make sdk' unless they're engaged in editing and publishing a
>> > new formal SDK. When you're working within the platform sources
>> > themselves, the distinction between public and private APIs is not
>> > particularly relevant. The primary 'make' build will enforce the
>> > current, existing API so that you don't inadvertently break anything,
>> > and that's all you need to worry about.
>> > (Note that typically nobody at Google runs 'make sdk' unless they are
>> > part of the group putting together a new SDK package.)
>> > Aha, yes, for the AOSP situation you're probably right that this is
>> > Step 0. jbq or someone, can you confirm?
>> >> 4. Once this is all done, an emulator should have been created that
>> >> has an SD card, allows GPS emulation, and pretty much all-around
>> >> works. Correct?
>> > Hrm. This does not create an sdcard image; you have to create one by
>> > hand. However, the emulator takes a command line argument "-sdcard"
>> > that lets you specify the image by path, no AVDs involved. AVDs are
>> > not part of the daily (or weekly or monthly or...) life of the Android
>> > framework engineers at 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.
While you do that, you may want to consider adding the "Google code
search" link, that enables search within the "package:android" It
will save everybody's time too.
On Thu, Aug 13, 2009 at 11:59 AM, Jean-Baptiste Queru<j...@android.com> wrote:
> I have a big item on my "todo" list to add a page on
> source.android.com to host that information, because it's indeed
> missing, and it's an unnecessarily steep part of the learning curve.
> JBQ
> On Thu, Aug 13, 2009 at 11:46 AM, Mike Lissner<mjliss...@gmail.com> wrote:
>> Thank you everybody for the detailed answers, since I know your time
>> is valuable. This should get me off to a better start with my
>> modifications to the code. I am quite pleased to get so many answers
>> directly from the horse's mouth (so to speak)!
>> The one question that I have now is why this process isn't on the
>> android development site? It took me a good deal of research to figure
>> out the above post, and it seems like the kind of hurdle that all
>> developers are going to have to jump right when they are starting to
>> get their feet wet.
>> Thanks again,
>> Mike
>> On Aug 12, 5:18 pm, Jean-Baptiste Queru <j...@android.com> wrote:
>>> I can confirm that the step 0 as mentioned used to be the right one -
>>> it might still work but I'm not sure.
>>> As for the sdcard, once you've built you should be able to create an
>>> SD image with mksdcard (run it with no arguments for the list of
>>> arguments), and use the resulting image with the -sdcard emulator
>>> argument that Chris mentioned.
>>> JBQ
>>> On Wed, Aug 12, 2009 at 4:35 PM, Christopher Tate<ct...@google.com> wrote:
>>> > My impressions, as a mostly-outsider to this discussion....
>>> > On Wed, Aug 12, 2009 at 4:23 PM, Mike Lissner<mjliss...@gmail.com> wrote:
>>> >> Questions:
>>> >> 1. Somewhere, I've left out the "lunch 1" command that does
>>> >> something....but where, and is it important?
>>> > 'lunch' is a shell command provided by the env_setup.sh configuration
>>> > step. It allows you to select among various products and build
>>> > flavors (eng, user, etc), and configures your environment
>>> > appropriately. Within Google's Android team, for example, this is
>>> > used all the time to switch between e.g. doing dream (G1 type
>>> > hardware) versus sapphire (Magic type hardware) builds, between
>>> > T-Mobile US vs Vodafone etc product bundles, etc.
>>> > If you just type 'lunch' with no argument, you should be presented
>>> > with a pick list of the most common / relevant options.
>>> >> 2. I'm a little confused why anybody would run make without running
>>> >> make sdk. Seems like you'd almost always want to make the sdk, but I'm
>>> >> probably missing something here.
>>> > I think the opposite: nobody working with the main source base should
>>> > ever run 'make sdk' unless they're engaged in editing and publishing a
>>> > new formal SDK. When you're working within the platform sources
>>> > themselves, the distinction between public and private APIs is not
>>> > particularly relevant. The primary 'make' build will enforce the
>>> > current, existing API so that you don't inadvertently break anything,
>>> > and that's all you need to worry about.
>>> > (Note that typically nobody at Google runs 'make sdk' unless they are
>>> > part of the group putting together a new SDK package.)
>>> > Aha, yes, for the AOSP situation you're probably right that this is
>>> > Step 0. jbq or someone, can you confirm?
>>> >> 4. Once this is all done, an emulator should have been created that
>>> >> has an SD card, allows GPS emulation, and pretty much all-around
>>> >> works. Correct?
>>> > Hrm. This does not create an sdcard image; you have to create one by
>>> > hand. However, the emulator takes a command line argument "-sdcard"
>>> > that lets you specify the image by path, no AVDs involved. AVDs are
>>> > not part of the daily (or weekly or monthly or...) life of the Android
>>> > framework engineers at 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.
> 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.
Oh, good idea, I'll put that on the todo list too.
(FWIW, we're investigating the possibility of storing the files for
source.android.com directly in the source tree, so that anyone can
contribute improvements to the web site).
On Thu, Aug 13, 2009 at 12:48 PM, Jey Michael<jey.mich...@gmail.com> wrote:
> While you do that, you may want to consider adding the "Google code
> search" link, that enables search within the "package:android" It
> will save everybody's time too.
> -Jey
> On Thu, Aug 13, 2009 at 11:59 AM, Jean-Baptiste Queru<j...@android.com> wrote:
>> I have a big item on my "todo" list to add a page on
>> source.android.com to host that information, because it's indeed
>> missing, and it's an unnecessarily steep part of the learning curve.
>> JBQ
>> On Thu, Aug 13, 2009 at 11:46 AM, Mike Lissner<mjliss...@gmail.com> wrote:
>>> Thank you everybody for the detailed answers, since I know your time
>>> is valuable. This should get me off to a better start with my
>>> modifications to the code. I am quite pleased to get so many answers
>>> directly from the horse's mouth (so to speak)!
>>> The one question that I have now is why this process isn't on the
>>> android development site? It took me a good deal of research to figure
>>> out the above post, and it seems like the kind of hurdle that all
>>> developers are going to have to jump right when they are starting to
>>> get their feet wet.
>>> Thanks again,
>>> Mike
>>> On Aug 12, 5:18 pm, Jean-Baptiste Queru <j...@android.com> wrote:
>>>> I can confirm that the step 0 as mentioned used to be the right one -
>>>> it might still work but I'm not sure.
>>>> As for the sdcard, once you've built you should be able to create an
>>>> SD image with mksdcard (run it with no arguments for the list of
>>>> arguments), and use the resulting image with the -sdcard emulator
>>>> argument that Chris mentioned.
>>>> JBQ
>>>> On Wed, Aug 12, 2009 at 4:35 PM, Christopher Tate<ct...@google.com> wrote:
>>>> > My impressions, as a mostly-outsider to this discussion....
>>>> > On Wed, Aug 12, 2009 at 4:23 PM, Mike Lissner<mjliss...@gmail.com> wrote:
>>>> >> Questions:
>>>> >> 1. Somewhere, I've left out the "lunch 1" command that does
>>>> >> something....but where, and is it important?
>>>> > 'lunch' is a shell command provided by the env_setup.sh configuration
>>>> > step. It allows you to select among various products and build
>>>> > flavors (eng, user, etc), and configures your environment
>>>> > appropriately. Within Google's Android team, for example, this is
>>>> > used all the time to switch between e.g. doing dream (G1 type
>>>> > hardware) versus sapphire (Magic type hardware) builds, between
>>>> > T-Mobile US vs Vodafone etc product bundles, etc.
>>>> > If you just type 'lunch' with no argument, you should be presented
>>>> > with a pick list of the most common / relevant options.
>>>> >> 2. I'm a little confused why anybody would run make without running
>>>> >> make sdk. Seems like you'd almost always want to make the sdk, but I'm
>>>> >> probably missing something here.
>>>> > I think the opposite: nobody working with the main source base should
>>>> > ever run 'make sdk' unless they're engaged in editing and publishing a
>>>> > new formal SDK. When you're working within the platform sources
>>>> > themselves, the distinction between public and private APIs is not
>>>> > particularly relevant. The primary 'make' build will enforce the
>>>> > current, existing API so that you don't inadvertently break anything,
>>>> > and that's all you need to worry about.
>>>> > (Note that typically nobody at Google runs 'make sdk' unless they are
>>>> > part of the group putting together a new SDK package.)
>>>> > Aha, yes, for the AOSP situation you're probably right that this is
>>>> > Step 0. jbq or someone, can you confirm?
>>>> >> 4. Once this is all done, an emulator should have been created that
>>>> >> has an SD card, allows GPS emulation, and pretty much all-around
>>>> >> works. Correct?
>>>> > Hrm. This does not create an sdcard image; you have to create one by
>>>> > hand. However, the emulator takes a command line argument "-sdcard"
>>>> > that lets you specify the image by path, no AVDs involved. AVDs are
>>>> > not part of the daily (or weekly or monthly or...) life of the Android
>>>> > framework engineers at 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.
>> 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.
