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. Suspicious TCP RST packets while device is sleeping.

Hey Bob,

Thanks a lot for the response :)

After a few more hours tonight working on the problem, I've got a bit more
information to present.

at the network level (tmobile I'd imagine).  The connection is definitely
NAT'd, the client sees itself as one outgoing IP ( and port,
and the server sees an incoming connection from a different IP/port

My best guess is that tmobile is killing the connections at the NAT level
after not seeing traffic running on it for a certain period of time (5
minutes in this case).  This wouldn't be a problem, as you said, a reconnect
works just fine.  And in fact, the higher-level long-lived session control
is already in place, and the client reconnects/etc properly when sensing a

The problem comes in based on _how_ the NAT is killing the connection.
 Keeping a wake-lock on device to prevent sleeping, and watching TCPdump on
both sides shows the server receiving a RST packet, but no RST packet is
sent to the client.  The client sits there, assuming the connection is still
active, indefinitely.  The second it tries to do something (user-prompted,
or via a "ping" timer), it sends a PSH packet to the server, and the server
responds with a RST (it closed the connection when it got the RST from the

Obviously if the NAT were to send RSTs both directions, this wouldn't be a
problem, the client would notice the disconnect, and reconnect.  But from
everything I can tell, it notifies the server, and leaves the client
completely unaware that the connection has been dropped...

I understand that the NAT needs to clear out old/stale connections, but
sending a RST uni-directionally seems a bit incorrect to me...

Any ideas?

- Dan


2. concept of "user name"


Is there a concept of "user name" in Android? Windows Mobile lets you
enter a description of the owner of the phone; Palm OS has the concept
of user name. But i couldn't find anything about this in Android.




3. Coloring Default Buttons - color filter only on unfocused state

4. Porting Android SDK For large screen devices.

5. Educational Resources

6. Vertical scrollview disappears on vertical and horizontal scrollview scheme

7. Dynamic TableLayout problem