Develop Reference

Measure elapsed time between some code segments in Android

everyone. I'm a newbie to android, so please forgive me for asking questions that may be a bit elementary.
I need to calculate the running time (in nanoseconds) of a code segment, and I just started using System.nanoTime(), something like this:
long startTime = System.nanoTime();
// some code seqment
long endTime = System.nanoTime();
long elapsedTime = startTime - endTime;
But I've observed online that sometimes elapsedTime is a negative number! After checking, it seems that the problem is due to the size of the cores in android, the frequency of the two cores is different and if my starttime and endTime run on different cores, the calculation is not credible.
I found elapsedRealTime,elpseRealTimeNanos, in the android documentation and they seem to meet my needs, but I don't know if they have the same problem as System.nanoTime, and I didn't find them on google, so I would like to ask if these two functions can meet my needs

It must be endTime - startTime to get positive number.
long elapsedTime = endTime - startTime;
OR you can try to use elapsedRealtime. (Not that it changed if device is reboot).
val startTime = SystemClock.elapsedRealtime()
// your code segment
val elapsedTime = SystemClock.elapsedRealtime() - startTime

Is it possible to monitor the CPU,Memory usage of each method in Android

I have my Android app with lots of methods and maybe each method runs for 1000s of lines. I need to monitor the CPU,memory usage in time duration(ms) of each method so that i can know which method is taking lot of CPU,memory and i can optimize it later. Is this possible? Any solution/advise would be of great help :)

I finally found out how to do this -
//Calculate function execution time
double start = System.currentTimeMillis();
double end = System.currentTimeMillis();
double t = (end - start);
//Calculate the amount of time that the current thread has spent executing code or waiting for certain types of I/O.
double start1 = Debug.threadCpuTimeNanos();
double end1 = Debug.threadCpuTimeNanos();
double t1 = (end1 - start1)/1000000;
//CPU Usage
double cpu = (t1/t) * 100;
//if t=0,cpu becomes infinity programmatically but it means cpu usage is 0.

You could set 2 DateTime variables, one at the start, one at the end.
Time start= new Time();
now.setToNow();
//Your method
Time end = new Time();
now.setToNow();
Distract the start from the start and see how long it takes.
Log the result: Log.I("METHOD_NAME", "duration");

Consider using Profiling with Traceview.
This can help you trace the timeline of each thread/method etc. Look at the link below.
http://developer.android.com/tools/debugging/debugging-tracing.html#traceviewLayout

opengl android time too fast

I'm trying to get the time using android and open gl for my racing game.
My code now is:
deltaTime = (System.currentTimeMillis() + startTime) / 1000000000000.0f;
startTime = System.currentTimeMillis();
tickTime += deltaTime;
DecimalFormat dec = new DecimalFormat("#.##");
Log.d("time", dec.format(tickTime/100));
but it's a bit too fast.

You may want to look at a bit of Android Breakout:
http://code.google.com/p/android-breakout/source/browse/src/com/faddensoft/breakout/GameState.java#1001
The computation is similar, but note it uses System.nanoTime(), which uses the monotonic clock. You don't want to use System.currentTimeMillis(), which uses the wall clock. If the device is connected to a network, the wall clock can be updated, which can cause big jumps forward or backward.
The code also includes a (disabled) frame-rate-smoothing experiment that didn't seem to matter much.
As I think you discovered, the key to this approach is to recognize that the time interval between frames is not constant, and you need to update the game state based on how much time has actually elapsed, not a fixed notion of display update frequency.

Since you're working in milliseconds, shouldn't you be dividing by 1000f instead of 1000000000000.0f?

Android Dev: Timer not honoring dynamic interval period

im working on a audio profile switcher for android and as part of the entire project, i have a service that is running in the background using the following timer code:
timer.scheduleAtFixedRate( new TimerTask() {
public void run() {.....}, 0, nextUpdateInterval);
what im noticing is that the timer is not honoring the dynamically generated next update interval period...the nextUpdateInterval is declared as private static long which is initialized to 30000 (30 seconds) for the first run....then once a profile is found, i do some math and update the nextUpdateInterval...i have converted the nextUpdateInterval value back out to hours/minutes for debugging purpose, and the calculation is working as expected...like it shows me in hours and minutes, when the next timer execution should take place...
nextUpdateInterval calculation: long entirePeriodDiff = toTimeMiliseconds - fromTimeMiliseconds;
then once a profile is found, i calculate the elapsedTime like so: long elapsedTime = rightNowDate.getTime() - fromDate.getTime();
and then i update the nextUpdateInterval: nextUpdateInterval = entirePeriodDiff - elapsedTime;
one example scenario: Profile of 'Work' is set from 9AM to 4:30PM, the service/app is executed at 2:02PM (EST), my toast message is executing constantly and is acting as a count down telling me how much time is left...in this case 2:28 and decreasing...ideally this should not display until the 2:28 is up...any ideas?

As per android doc:
With fixed-rate execution, the start time of each successive run of a task is scheduled without regard for when the previous run took place. This may result in a series of bunched-up runs (one launched immediately after another) if delays prevent the timer from starting tasks on time.
I think that could be the reason, may be you need to consider alternative 'fixed period'

Android Sensor Timestamp reference time

I'm reading timestamp values from SensorEvent data but I can't work out the reference time for these values. Android documentation just says "The time in nanosecond at which the event happened" As an example:
My current Android device date, October 14th 2011 23:29:56.421 (GMT+2)
System.currentTimeMillis * 1000000 (nanosec) = 1318627796431000000 (that's ok)
sensorevent.timestamp (nanosec) = 67578436328000 = 19 hours 46 min ????
May you help me?
thanks

It appears that what you are dealing with is the number of nanoseconds since the operating system started, also known as "uptime".
Further info on the issue: http://code.google.com/p/android/issues/detail?id=7981
I should add that the linked question SensorEvent.timestamp to absolute (utc) timestamp? deals with the same issue and is where I found the answer.

I know that it's a very old question, but, I'm also struggling for converting SensorEvent.timestamp to a human readable time. So I'm writing here what I've understood so far and how I'm converting it in order to get better solutions from you guys. Any comments will be welcomed.
As I understood, SensorEvent.timestamp is an elapsed time since the device's boot-up. So I have to know the uptime of the device. So if there is an API returning device's boot-up, it will be very easy, but, I haven't found it.
So I'm using SystemClock.elapsedRealtime() and System.currentTimeMillis() to 'estimate' a device's uptime. This is my code.
private long mUptimeMillis; // member variable of the activity or service
...
atComponentsStartUp...() {
...
/* Call elapsedRealtime() and currentTimeMillis() in a row
in order to minimize the time gap */
long elapsedRealtime = SystemClock.elapsedRealtime();
long currentTimeMillis = System.currentTimeMillis();
/* Get an uptime. It assume that elapsedRealtime() and
currentTimeMillis() are called at the exact same time.
Actually they don't, but, ignore the gap
because it is not a significant value.
(On my device, it's less than 1 ms) */
mUptimeMillis = (currentTimeMillis - elapsedRealtime);
....
}
...
public void onSensorChanged(SensorEvent event) {
...
eventTimeMillis = ((event.timestamp / 1000000) + mUptimeMillis);
Calendar calendar = Calendar.getInstance();
calendar.setTimeInMillis(eventTimeMillis);
...
}
I think this works for Apps that a millisecond time error is okey. Please, leave your ideas.