Develop Reference

Unresolved inclusion: <algorithm> eclipse Android

Why is not in my NDK algoritmh.h???? how can i make my std::Sort???? of 1d array
/----------------------------------------------------------
Solved the 2nd question::
and 2. question:my other code started says this error:) SOlved!
Multiple markers at this line
- call of overloaded 'log(int)' is
ambiguous
- candidates are:
in this code:
int m = (int) (log (524288) / log (2));
OK this is solved

std::log has overloads that accept float, double or long double as parameters. The compiler doesn't know which function you are asking for.
Try:
int m = (int) (log (524288.) / log (2.));
Notice that the parameters to log() are now double, not int.

simulating drag using monkeyrunner

I have android ics-x86 and i need to simulate drag event but device.drag is giving error
it is giving me class cast exception.i have called it like this-
x=(67.8,100.0)
y=(267.8,100.0)
device.drag(x,y,10.0,10)
what is wrong with the arguments??please help!

device.drag (tuple start, tuple end, float duration, integer steps)
example: device.drag((350, 620), (13, 620), 0.5, 50)

Why does the matrix generated by Android's frustumM differ from the Redbook's?

Something seems funny about the way that Android's frustumM works. If I check the OpenGL red book, the matrix generated looks like this:
(source: glprogramming.com)
Songho.ca seems to agree with this:
(source: songho.ca)
However, one component is multiplied by 2 with Android's frustumM, and not in the other example matrices. Here's what it seems to be doing:
Everything seems to functionally match up, except the first row, third column. Why is that being multiplied by two? Here's the lines of code from android.opengl.Matrix's frustumM method that generate the first three elements of the third column:
final float A = 2.0f * ((right + left) * r_width);
final float B = (top + bottom) * r_height;
final float C = (far + near) * r_depth;
With r_width, r_height, r_depth defined as:
final float r_width = 1.0f / (right - left);
final float r_height = 1.0f / (top - bottom);
final float r_depth = 1.0f / (near - far);
The line starting with "final float A" appears to be mistakenly multiplying by 2.
Is this a mistake in Android's code, or am I just missing something? I know that the term cancels out if the frustum is symmetrical. When running the code with an asymmetrical frustum, the generated matrices actually are different and so are the resulting vectors when the same vector is multiplied with those differing matrices.

It's a bug with Android. Please see http://code.google.com/p/android/issues/detail?id=35646

((I'd preffer just to comment but I'm not allowed.))
Thank you guys for the insight. I just had to add
mMyMatrix[8] /= 2f;
after
Matrix.frustrumM(mMyMatrix, ...)
To solve my aspect ratio problems :)

yes, if you call the function with a (-ratio, ratio, -1, 1, 1, 10) parameters set, it does not cause the probelm, but if you call with (right != -1 * left), it makes thing different.
I find this issue when i check the source code. sigh.

Canvas not displaying all drawn parts in Custom View?

I'm working on a custom view for an android application, similar to the Analog Gauge sample code available from Mind the Robot.
Running the code from listed site, I get see this on my screen:
(Motorola Droid, 2.2.3), (Emulator, 4.0.3)
(Xoom, 4.0.3)(Other phone, 4.0.3)
The hand is missing!
The drawing calls are being made (I can see them in logcat), but the canvas elements the calls draw are invisible.
It's not API level dependent, though; if I import it the right way into a project, it will hand will show up when I run it on the Xoom.
But, when I move the files to a different project folder (same source code, same layouts) it goes back to missing the dial.
What's going on? How could the same code be producing such different outcomes on different devices?

So, the key clue in my mystery seemed to be that it worked on the emulator, but not on the hardware devices.
Hardware Rendering
I did peruse the hardware rendering page on the Android Developer's website, but apparently not closely enough.
http://developer.android.com/guide/topics/graphics/hardware-accel.html
While it does mention that the API's are available beginning version 11, it does not say that Hardware Rendering is turned on for all applications by default, starting with API Level 14 (ICS).
What does this mean for us?
Almost everything is faster; except for the few things that don't work.
I managed to violate two of these, without realizing it:
Canvas.DrawTextOnPath()
Paint.setShadowLayer()
It's not mentioned in the API reference (or anywhere else I can find, and certainly not checked by Lint), but using any of the listed operations can do weird things.
In my case, Canvas.DrawTextOnPath() seemed to work just fine.
But when Android notice that the paint that I used on the hand had shadow layer set, it silently ignored it.
How do I know if my View is hardware accelerated?
From the documentation link above:
There are two different ways to check whether the application is hardware accelerated:
View.isHardwareAccelerated() returns true if the View is attached to a hardware accelerated window.
Canvas.isHardwareAccelerated() returns true if the Canvas is hardware accelerated
If you must do this check in your drawing code, use Canvas.isHardwareAccelerated() instead >of View.isHardwareAccelerated() when possible. When a view is attached to a hardware >accelerated window, it can still be drawn using a non-hardware accelerated Canvas. This >happens, for instance, when drawing a view into a bitmap for caching purposes.
In my case, the opposite appears to have occurred.
The custom view logs that it is not Hardware-accelerated; however, the canvas reports that it is hardware-accelerated.
Work Arounds and Fixings
The simplest fix is forcing the custom view to do software rendering. Per the documentation this can be accomplished by:
myView.setLayerType(View.LAYER_TYPE_SOFTWARE, null);
Alternatively, you could remove the offending operations, and keep hardware rendering turned on.
Learn from my misfortune. Good luck, all.

I put it into init() and worked fine after that.
private void init() {
setLayerType(myView.LAYER_TYPE_SOFTWARE, null);
....
}

With myView.setLayerType(View.LAYER_TYPE_SOFTWARE, null); suggestion I can see hand. But I have still a problem: I see scale with only 0 written! As in the picture and two strage zeros out of the schema: (GALAXY NEXUS 4.2.1)
My drawScale() method is as in the example:
private void drawScale(Canvas canvas) {
canvas.drawOval(scaleRect, scalePaint);
canvas.save(Canvas.MATRIX_SAVE_FLAG);
for (int i = 0; i < totalNicks; ++i) {
float y1 = scaleRect.top;
float y2 = y1 - 0.020f;
canvas.drawLine(0.5f, y1, 0.5f, y2, scalePaint);
if ((i % 5) == 0) {
int value = nickToDegree(i);
if ((value >= minDegrees) && (value <= maxDegrees)) {
String valueString = Integer.toString(value);
canvas.drawText(valueString, 0.5f, y2 - 0.015f, scalePaint);
}
}
canvas.rotate(degreesPerNick, 0.5f, 0.5f);
}
canvas.restore();
}

in my case i made this:
AnalogView bar = (AnalogView) findViewById(R.id.AnalogBar);
bar.setLayerType(bar.LAYER_TYPE_SOFTWARE, null);
if (value_list.size()>0) bar.SetData(Double.parseDouble(value_list.get(value_list.size()-1)));
where SetData in AnalogView is
public void SetData(double data) {
setHandTarget((float)data);
invalidate();
}

On Galaxy S4 Android 4.4.2
TYPE_TEMPERATURE is deprecated
use
TYPE_AMBIENT_TEMPERATURE

For anyone having problems with text drawing on scale in the initialisation do this:
scalePaint.setLinearText(true);

Android NDK fload addition accuracy

I have a problem.
I am calculating position of some points for opengl rendering.
But calculations are wrong and it results with one pixel overlap on rendered image.
And its a serious problem because it looks nasty.
Strangest thing is that error occurs with simple addition.
I am just adding 0.02 for every row and column and there is a 0,009 from nowhere.
Any ideas where its coming from?
I have tried to change compiler from arm7 to arm and it does not help
code :
for (int i=0;i<elem;i++)
{
LOGE("ROW: %d",i);
startPosX = -(float)elem*vertSize/2.0f + vertSize/2.0f;
for (int j=0;j<elem;j++)
{
LOGE("Column: %d",j);
LOGE("x: %f y: %f vs:%f",startPosX,startPosY,vertSize);
Vvertices[((i*elem*3)+j*3+0)] = startPosX;
Vvertices[((i*elem*3)+j*3+1)] = startPosY;
Vvertices[((i*elem*3)+j*3+2)] = z;
positions[i*elem+j].Set( startPosX, startPosY, z );
if(randomType)
velocity[i*elem+j].Set(getRandom()/speed,getRandom()/speed,getRandom()/speed);
else
velocity[i*elem+j].Set(0.0f,0.1f/speed,0.0f);
startPosX+=vertSize;
}
startPosY +=vertSize;
}
Column: 85
x: 0.710000 y: 0.989999 vs:0.020000
Column: 86
x: 0.729999 y: 0.989999 vs:0.020000

When you need assured precision for mathematical calculations it can sometimes be a bad idea to use types such as float, because many numbers do not have a finite representation in binary, just like some fractions do not have a finite representation in decimal.
This problem has to do with the machine representation of the numbers and not with the programming language you are using itself. Many languages with the typical ways of handling float and double types have this issue.
In Java people use classes such as BigDecimal to deal with this kind of problem.