by Stefan » Wed, 09 Feb 2011 22:34:03 GMT

Sponsored Links
 I'm not sure, maybe it's a dumb question, but anyway:

When I want to start Android, and I use the images from the
sdk I have to adjust the init.rc file. But what happens with the
init.goldfish.rc file which is in the same directory?

Shall I delete it and make my own init.<architecture>.rc file?

If yes, what shall I write into this file?




Re: init.<architecture>.rc

by Joerie de Gram » Thu, 10 Feb 2011 00:52:17 GMT


It's evaluated for the goldfish (emulator) board. It's not
architecture, but board specific. On bootup it attempts to run
init.<boardname>.rc, where boardname is the kernel supplied board
name, lowercase (and if it contains spaces, up to the first space).

Anything to be performed at init, specific to your board.



Sponsored Links

Re: init.<architecture>.rc

by Stefan » Fri, 11 Feb 2011 17:19:40 GMT

 > It's not architecture, but board specific.

So, I have to delete the goldfish-init and write my board specific

What do I have to write into e.g. init.myOwnBoard.rc if I "only"
want to start Android as I can see it running on the emulator?

Do I have to edit the normal init.rc too for this?

Would you be so kind and give me an example for a running init.XXX.rc-


Re: Re: init.<architecture>.rc

by David Turner » Fri, 11 Feb 2011 21:58:32 GMT


board-specific initialization.
It could defining new services, mounting partitions, defining system
properties, whatever.

Apart from that, consider it an extension of init.rc

It really depends on the customization you have done.


I.e. if you modify the platform in significant ways, you would modify
init.rc to reflect that.
You could then use the same platform to build various product configurations
(each corresponding to a different board), and put their own customizations
in init.<board1>.rc, init.<board2>.rc, etc...

Of course, if all you do is developing a single product/board, you can just
modifiy init.rc instead.

Would you be so kind and give me an example for a running init.XXX.rc-


Other Threads

1. G1 Firmware Builds only For Developers? my Demand to Google / HTC / TMobile

I think being a Open Source Code and Openness in Architecture, API
Google Should Ship Different Firmware for Developers, Software
Builders, Codec Programmer etc.

Better for Google / T-Mobile / HTC

   1. They can restrict Developer Device to get Back Normal Shipped
   2. Developer Device Activation Method can be Introduced so Once you
Activate that IMEI for Developer Edition you could get only Limited
Warranty from HTC for that IMEI.
   3. Once you load Different Firmware, company may not allow you to
Flash Normal Shipped / OTA Firmware signed by Different Signature.
   4. Developer Edition of Firmware can have Test Key or Developer Key
based Recovery Partition. But can not Erased the way we did it before.
   5. Developer firmware must be only available via SDCard Method
   6. No OTA should be given except for some killbits Urgency.
   7. Their should be Disclaimer and Agreement for Warranty Issue

Better for Developers

   1. Rather then Fighting for root this could be Straight Access to
   2. No More Hacking and Exploits needed.
   3. Building Firmware, API, Services, Codes which need Root Access
can be Tested with Device rather then Emulator.
   4. Customizing OS and using it for Self and Distributing it to user
who can take risk may get easy Access to Mods.
   5. Google Should Protect Recovery Image and Boot Image from being
Flashed this will reduce Bricking Issue.

Hetal Patel


2. Free killer app idea

I can't program worth a crap, so I submit this idea to programmers of
all skill levels.

A program which uses the internal camera of the Android phone, it
scans for text or characters within the camera view and automatically
translates the characters into another language and displays it on

As an example, you're in Japan and you don't know if a sign says
'Police Station' or 'Maid Cafe' you can point your Android phone at
the sign and the phone will translate the characters into a language
you can understand.

If someone develops such an app thanks to my idea, please credit me
somewhere.  8*)


3. :: problem with TextSwitcher

4. android porting with nfs shut dowb VM err

5. Getting user's phone number

6. Simulate KeyEvent

7. Android compilation error with Sun SDK 1.6.0 Update 10