Updating cupcake Images to Android Developer Phone

by abhijithvr » Wed, 29 Apr 2009 22:14:29 GMT

Sponsored Links

I am working on the cupcake code .We recently bought a ADP phone and
following the steps in

www.htc.com/www/support/android/adp.html , i upgraded to the phone to
Android 1.5 using the images given in the link .

 What we need, is to install the system.img created from compiling the
cupcake source.

 How will I do that ? Any idea ?

 I am able to install my image to the phone by replacing the
system.img of the image zip from HTC with my image.But that
system.image is not identifying the operator network,.

We are doing something on managing voice calls . So we need to use the

Is there any way I can create image which will support a GSM SIM from
cupcake . May be some "make" options.?


 http://groups.google.co.in/group/Android-DevPhone-Updating/browse_thread/thread/8eaa46d05219ec4c/9e5274e90b9e2d26?q=Updating +new+Images+to+Android+Developer+Phone#9e5274e90b9e2d26


Other Threads

1. What is the definitive/official situation regarding native development/JNI?

I would like to know what the definitive, hopefully official,
situation regarding native development.

Whenever anybody posts a question regarding native development the
stock answer that is given is "There is no support for native

I simply want to know the answers to:
1) If I want to write/port a C/C++ application engine and write a Java
App that accesses it, how can this be achieved?

2) If this is not possible, will it be possible in the future? If so

3) Is this is not possible, is it only not possible for 3rd party
developers? If I am a hugh corporation, suppose I'm SAP or Oracle, or
a major international games developer and have multi-million selling
products in C/C++ that I wish to port to Android, are Google going to
tell me sorry its not possibe? Are they really going to say that? If
not then who do you talk to in order to open doors?


2. What is the definitive/official situation regarding native development/JNI?

that's easy, writing third-party apps containing native code is *officially*
*not* *supported*.
Which is our way to say that if you do it, don't be surprised if your app
breaks due to system
changes or have weird support issues.

(Note that this is different if you are directly poking at the framework
code to prepare a new
Android-based system/product).

this is possible through clever hacks that won't be described here because
these apps
are very likely to break in one of the next release of the platform.

We are preparing a Native Development Kit that will allow you to embed
native libraries in your
application that your Java app will call through JNI. However there is a
catch: the set of system
interfaces your C/C++ code will be able to call will be very strictly
limited (e.g. libc + libm + jni.h)

Any attempt to call one of the system libraries like Skia, Webcore and other
will fall under the
*unsupported* case and *will* break in future releases of the system.

The set of supported NDK native interfaces might gorw a little to include
stuff like OpenGL in
the more distant future, but will always remain very limited by design. That
should be enough
for many games and signal-processing apps.

If you are a large corporation, just use the Android sources to build your
own system
and distribute them to your employees and/or customers. Of course you'll
also do al
the support. However, your native apps will probably not run properly on
Android-based systems.


3. Announcing new documents for OpenCORE

4. Application did not load to market place now the app is gone, please help

5. Is it possible to have 2 launcher Activity in a single apk?

6. 2 questions about Browser

7. is Android Market removing useless comments now?