Hi,
I'm struggling to find a solution to this problem.
I have a device with the following definitions:
emev.mk:PRODUCT_NAME := renesas_emev
emev.mk:PRODUCT_DEVICE := emev
emev.mk:PRODUCT_BOARD := emev
PRODUCT_COPY_FILES += \
$(LOCAL_PATH)/init.rc:root/init.rc \
Sorry, forgot to mention that the content of init.emxx.rc is a call to
init.emev.sh:
-
on boot
setprop net.dns1 192.168.0.1
setprop ro.radio.use-ppp no
setprop ro.radio.noril yes
setprop ro.showcursor 1
chown system system /sys/class/leds/led1/brightness
chown
... and the complete set of product names (in my emev.mk) is:
PRODUCT_NAME := renesas_emev
PRODUCT_DEVICE := emev
PRODUCT_BOARD := emev
PRODUCT_BRAND := emxx
PRODUCT_MANUFACTURER := renesas
On Friday, 7 December 2012 11:43:43 UTC+1, ffxx68 wrote:
Sorry, forgot to mention that the content of
On Friday, December 7, 2012 4:11:46 PM UTC+5:30, ffxx68 wrote:
Hi,
I'm struggling to find a solution to this problem.
I have a device with the following definitions:
emev.mk:PRODUCT_NAME := renesas_emev
emev.mk:PRODUCT_DEVICE := emev
emev.mk:PRODUCT_BOARD := emev
PRODUCT_COPY_FILES +=
the machine name from kernel is
cd arch/arm/mach-emxx
grep MACHINE_START *.c
emev_board.c:MACHINE_START(EMXX, EMXX)
So, looks like I need an init.EMXX.rc file... Does lower/upper case count?
I'm puzzled, because I had exactly the same files in my GB version and it
worked seamlessly. In JB
btw - thanks Vishveshwar!
On Friday, 7 December 2012 16:29:34 UTC+1, ffxx68 wrote:
the machine name from kernel is
cd arch/arm/mach-emxx
grep MACHINE_START *.c
emev_board.c:MACHINE_START(EMXX, EMXX)
So, looks like I need an init.EMXX.rc file... Does lower/upper case
count?
I'm
I find no message about init..rc as you said in kernel or logcat boot.
I've also tried with these init..rc names:
init.EMXX.rc
init.emev.rc
but still the script isn't called I'm getting crazy with it!
What's irritating is that calling it manually everything goes fine.
What else to
I was looking for the same kind of info too.
What are the contact points?
Do you need to get in touch with a Google sales rep?
On Wednesday, 5 December 2012 07:51:31 UTC+1, Jacob wrote:
Your company needs business agreement in place with Google Android team.
On Tue, Dec 4, 2012 at 10:00 AM,
You can, alternatively, specify androidboot.hardware=emev to the kernel
cmdline in your bootloader, or boot.img, whatever.
ffxx68於 2012年12月7日星期五UTC+8下午6時41分46秒寫道：
Hi,
I'm struggling to find a solution to this problem.
I have a device with the following definitions:
emev.mk:PRODUCT_NAME
W/dalvikvm( 287): Cached DEX '/system/framework/android.policy.jar'
(/data/dalvik-cache/system@framew...@android.policy.jar@classes.dex) is
stale and not writable
Looks like it's mounted read-only.
--
unsubscribe: android-porting+unsubscr...@googlegroups.com
website:
Hi Everyone,
I have a shared library which is used by multiple processes.
In this library I create a thread when this module is started and listen on
a local socket.
Each process provides a callback to this module and upon receiving the
response it informs the corresponding process.
The
On Thursday, 6 December 2012 05:38:59 UTC+1, Ranganath TM wrote:
I am working on ICS, and I don't the procedure how to build the source and
create image for emulator. kindly give me the steps how to achieve it.
http://source.android.com/source/initializing.html
--
unsubscribe:
Looks like even on the emulator the ConnectivityService is setting up the
net.dns* properties.
It looks like in the full build (full-eng), the telephony components (via
full_base_telephony.mk) is being included. This seems to trigger the
addition of the net.dns* properties through a chain
Here's one method I can think of : Lookup the file that sources the vendor
specific file; I believe this is /init.rc. This would have a line like
import /init.${ro.hardware}.rc (looking at aosp).
Now, get a shell on the device and execute getprop ro.hardware. This
should give you the right
you need to create the sysfs interface path that reads the data you are
interested in. And also you need to provide the rite permission in for that
sysfs path in the init.rc file. By the way to what type of device you wrote
the i2c driver, and till what extent your achieved in the driver.
Thanks
Thanks Shree. I will check that, but could you please elaborate about the
initrd? How could I verify that?
--
unsubscribe: android-porting+unsubscr...@googlegroups.com
website: http://groups.google.com/group/android-porting
16 matches
Mail list logo
