NDK all from within Eclipse

by Robert Green » Wed, 16 Dec 2009 07:02:13 GMT


Sponsored Links
 I was going to post this to the group but figured I'd write up a how-
to on my website instead.  Basically, here's how you configure Eclipse
to do nice C/C++ editing and automatically build your native code for
you on-save.  It also automatically refreshes your lib directory and
consequently ADT puts it straight into your APK.

 http://www.rbgrn.net/content/348-get-your-eclipse-integrated-ndk-on 

I'll post this to the NDK dev group as well.  I can't believe I didn't
set that up sooner.  It cut my native development time in half.  Let
me know if you have problems/questions with it.

--



NDK all from within Eclipse

by HeHe » Wed, 16 Dec 2009 10:56:57 GMT


 thanks! thanks! thanks!




--


Sponsored Links


NDK all from within Eclipse

by Paul Turchenko » Wed, 16 Dec 2009 16:11:33 GMT


 Really cool! Thanks a lot!




--



NDK all from within Eclipse

by datoudatou » Thu, 17 Dec 2009 02:18:24 GMT


 hi Robert Green,

great thanks.

i have tried your method, it really worked for me
(slackware 12.1, android sdk-2.1 + ndk1.6 + eclipse galileo + cdt 6.0.1).

now, i can declare that the method workes under win32 and linux dev env.


yours waynechen
2009.12.16




--



NDK all from within Eclipse

by Nightwolf » Fri, 18 Dec 2009 01:45:35 GMT


 There is also useful video

Using CDT for Android Native
 http://cdtdoug.blogspot.com/2009/09/using-cdt-for-android-native.html 

It would be great to know how to debug native code.






--



Other Threads

1. game source code

HI guys,

 would you share with me where can i get some android game souce code
like "angrybirds"...?

 i want to develop the game, but i don't know how start?

-- 

2. What is the recommended resolution/aspect ratio for android graphics

Hi All, I'm trying to write an application that will work well on all
screen sizes, for that I have my graphic designer produce images that
are in the requested dpis for each directory (Low density (120), ldpi,
Medium density (160), mdpi, High density (240), hdpi, Extra high
density (320), xhdpi) however, they want to know at which resolution
and aspect ratio each image should be, after looking around the
android documenation, namely: 1)http://developer.android.com/guide/
topics/resources/providing-resources.html#AlternativeResources
2)http://developer.android.com/guide/practices/screens_support.html I
came up with the following information: It is not exact that android
supports 3 screen sizes, android is an OS that can run virtually on
any screen size but there are some screen sizes that are more common
than others, these are demonstrated in the table below (taken from
http://developer.android.com/guide/practices/screens_support.html)

Table 1. Screen sizes and densities of emulator skins included in the
Android SDK. Low density (120), ldpi Medium density (160), mdpi High
density (240), hdpi Extra high density (320), xhdpi Small screen QVGA
(240x320)
Normal screen WQVGA400 (240x400) WQVGA432 (240x432) HVGA (320x480)
WVGA800 (480x800) WVGA854 (480x854)
Large screen WVGA800* (480x800) WVGA854* (480x854)
Extra Large screen

It worth noting here that even though it seems that there is no
correlation between these screen sizes, there is a 3:4:6 scaling ratio
between the three densities, so a 9x9 bitmap in ldpi is 12x12 in mdpi
and 18x18 in hdpi (see
http://developer.android.com/guide/topics/resources/providing-resources.html#AlternativeResources).

We can see some more information on what the screen sizes mean here:

Screen size small: Screens based on the space available on a low-
density QVGA screen. Considering a portrait HVGA display, this has the
same available width but less heightt is 3:4 vs. HVGA's 2:3 aspect
ratio. Examples are QVGA low density and VGA high density. normal:
Screens based on the traditional medium-density HVGA screen. A screen
is considered to be normal if it is at least this size (independent of
density) and not larger. Examples of such screens a WQVGA low density,
HVGA medium density, WVGA high density. large: Screens based on the
space available on a medium-density VGA screen. Such a screen has
significantly more available space in both width and height than an
HVGA display. Examples are VGA and WVGA medium density screens. xlarge: Screens that are considerably larger than the traditional
medium-density HVGA screen. In most cases, devices with extra large
screens would be too large to carry in a pocket and would most likely
be tablet-style devices. Added in API Level 9.

We can also support specific aspect ratios, as defined here:

Screen aspect long: Long screens, such as WQVGA, WVGA, FWVGA notlong: Not long screens, such as QVGA, HVGA, and VGA

-- All of this however, is not enough to answer the simple question of
what the resolution should be on those images - can they all be cut
from the same high res image or should they be re-done for each dpi
since the aspect ratio is different?
 Thanks!
P.s. To clarify, I'm talking about images that should take up the
entire screen - images such as backgrounds etc, and not just regular
images

-- 

3. Populate Spinner from database

4. Canvas vs OpenGl drawline speeds

5. Thickness strikethrough

6. How to setImageViewUri in Widget using getFileStreamPath()?

7. Receiving phone calls regarding Android Market billing issues?