Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Custom init.rc for recovery.img

193 views
Skip to first unread message

emeric....@gmail.com

unread,
Jan 25, 2016, 4:44:52 PM1/25/16
to mozilla-...@lists.mozilla.org
Hi,

A custom init.rc can be provided for boot.img by enabling TARGET_PROVIDES_INIT_RC flag (enabled by default in gonk-misc/b2g.mk).

Now, I would like to provide a custom init.rc for recovery.img too. I didn't find any information. And none of the variables in build/core/product.mk seems adequate. Is there actually a way to embed a custom init.rc in recovery.img?

Thanks,

Émeric

Alexandre Lissy

unread,
Jan 25, 2016, 4:48:46 PM1/25/16
to dev-...@lists.mozilla.org
Some of the logic for copying to recovery's ramdisk lives in
build/core/Makefile :)

>
> Thanks,
>
> Émeric
> _______________________________________________
> dev-fxos mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-fxos
>

emeric....@gmail.com

unread,
Jan 26, 2016, 12:25:02 PM1/26/16
to mozilla-...@lists.mozilla.org
Le lundi 25 janvier 2016 22:48:46 UTC+1, Alexandre Lissy a écrit :
>
> Some of the logic for copying to recovery's ramdisk lives in
> build/core/Makefile :)

Doh! Is simply copying a file sufficient to "make it work"?

I mean, to use custom init.rc in boot.img, you have to (i) set TARGET_PROVIDES_INIT_RC and (ii) append init.rc to PRODUCT_COPY_FILES in device.mk file, right? Or does (ii) implicitely implies (i)?

Émeric

Adam Farden

unread,
Jan 26, 2016, 3:55:11 PM1/26/16
to emeric....@gmail.com, mozilla-...@lists.mozilla.org
recovery init.rc is actually really simple, you probably don't need a custom init.rc you can add what you need in init.recovery.[platform].rc and it will be picked up automatically.

https://android.googlesource.com/platform/bootable/recovery/+/android-4.3_r1/etc/init.rc#1

On Tue, Jan 26, 2016 at 6:24 PM, <emeric....@gmail.com> wrote:
Le lundi 25 janvier 2016 22:48:46 UTC+1, Alexandre Lissy a écrit :
>
> Some of the logic for copying to recovery's ramdisk lives in
> build/core/Makefile :)

Doh! Is simply copying a file sufficient to "make it work"?

I mean, to use custom init.rc in boot.img, you have to (i) set TARGET_PROVIDES_INIT_RC and (ii) append init.rc to PRODUCT_COPY_FILES in device.mk file, right? Or does (ii) implicitely implies (i)?

emeric....@gmail.com

unread,
Jan 27, 2016, 11:49:34 AM1/27/16
to mozilla-...@lists.mozilla.org
Le mardi 26 janvier 2016 21:55:11 UTC+1, Adam Farden a écrit :
> recovery init.rc is actually really simple, you probably don't need a custom init.rc
> you can add what you need in init.recovery.[platform].rc and it will be
> picked up automatically.
>
> https://android.googlesource.com/platform/bootable/recovery/+/android-4.3_r1/etc/init.rc#1

Well, I've tried this approach before for custom init.rc in boot.img but don't know if it's really working. All I can say is, if I don't add init.[platform].rc to PRODUCT_COPY_FILES too, I'm not getting custom init.rc in boot.img, but the default one (yep, TARGET_PROVIDES_INIT_RC flag was set).

So I fear this will be the same for recovery.img.

BTW, how do you deal with priorities? I mean, if you have directives in "on early-init" section of how both init.recovery.[platform].rc and recovery's default init.rc, are the ones from init.recovery.[platform].rc parsed before the default ones? Or are all directives of all sections in init.recovery.[platform].rc parsed before default init.rc? I'm asking this, because the init.rc pulled from OEM recovery.img shows customization in this file, not in init.recovery.[platform].rc (that doesn't exist).

Émeric
0 new messages