I am recently working on a project aiming at evaluating whether an android app crashes or not. The evaluation process is:
Collect the logs(which record the execution process of an app).
Generate formulas to predict the result (formulas is generated by GP)
Evaluate the logs by formulas
Now I can produce formulas, but for convenience for users, I want to translate formulas into form of natural language and tell users why crash happened.(I think it looks like "inverse natural language processing".)
To explain the idea more clearly, imagine you got a formula like this:
155 - count(onKeyDown) >= 148
It's obvious that if count(onKeyDown) > 7, the result of "155 - count(onKeyDown) >= 148" is false, so the log contains more than 7 onKeyDown event would be predicted "Failed".
I want to show users that if onKeyDown event appears more than 7 times(155-148=7), this app will crash.
However, the real formula is much more complicated, such as:
(< !( ( SUM( {Att[17]}, Event[5]) <= MAX( {Att[7]}, Att[0] >= Att[11]) OR SUM( {Att[17]}, Event[5]) > MIN( {Att[12]}, 734 > Att[19]) ) OR count(Event[5]) != 1 ) > (< count(Att[4] = Att[3]) >= count(702 != Att[8]) + 348 / SUM( {Att[13]}, 641 < Att[12]) mod 587 - SUM( {Att[13]}, Att[10] < Att[15]) mod MAX( {Att[13]}, Event[2]) + 384 > count(Event[10]) != 1))
I tried to implement this function by C++, but it's quite difficult, here's the snippet of code I am working right now.
Does anyone knows how to implement this function quickly?(maybe by some tools or research findings?)Any idea is welcomed :)
Thanks in advance.
Related
I have the following code ( from a class member function of mine):
this->mLengOfPath = mFirst->mLengOfPath + mSecond->mLengOfPath;
unsigned short* data = mMiddle->mPathContainer;
mMiddle->mLengOfPath = 0;
for (int index = 0; index < mMiddle->mSize; index++) { //crash here
if (index % 2 == 1 && index > 2){
mMiddle->mLengOfPath +=
GestureUtils::distance(data[index - 3], data[index - 2],
data[index - 1], data[index]);
}
}
In most case, this code doesn't crash. But crashlytics told me that my code "sometimes" crash at line 4, which I don't understand why. If mMiddle is nullptr, it should have crashed at line 2 (I already use mMiddle there).
But crashlytics consistently reports that line 4 is the problem. Anyone know how can my code go wrong at line 4?
Yeah, it's UB, if pointer is invalid. But we have particular platform and compiler in mind, while talking Android NDK and a statistical tool. With native ARM code lines 1,2,4 lines may crash sometimes on invalid pointer, only writing to null pointer is 100% failure.
Line 3 will always fail if mMiddle is null, but may or may not if it points into data segment or not. Statistical tool would highlight line 4 as it is one more often executed one: comparing expression is evaluated on every iteration. Failures on other lines may become statistical noise.
For a school project I am creating an android app that involves streaming image data. I've finished all the requirements about a month and a half early, and am looking for ways to improve my app. One thing I heard of is using the android NDK to optimize heavily used pieces of code.
What my app does is simulate a live video coming in over a socket. I am simultaneously reading the pixel data from a UDP packet, and writing it to an int array, which I then use to update the image on the screen.
I'm trying to decide if trying to increase my frame rate (which is about 1 fps now, which is sufficient for my project) is the right path to follow for my remaining time, or if I should instead focus on adding new features.
Anyway, here is the code I am looking at:
public void updateBitmap(byte[] buf, int thisPacketLength, int standardOffset, int thisPacketOffset) {
int pixelCoord = thisPacketOffset / 3 - 1;
for (int bufCoord = standardOffset; bufCoord < thisPacketLength; bufCoord += 3) {
pixelCoord++;
pixelData[pixelCoord] = 0xFF << 24 | (buf[bufCoord + 2] << 16) & 0xFFFFFF | (buf[bufCoord + 1] << 8) & 0xFFFF | buf[bufCoord] & 0xFF;
}
}
I call this function about 2000 times per second, so it definitely is the most used piece of code in my app. Any feedback on if this is worth optimizing?
Why not just give it a try? There are many guides to creating functions using NDK, you seem to have a good grasp of the reasoning to do so and understand the implications so it should be easy to translate this small function.
Compare the two approaches, you will no doubt learn something which is always good, and it will give you something to write about if you need to write a report to go with the project.
How to convert WiFi level (i.e. -45 , -88 ) in to percentage ?
I want to convert WiFi level in % . I get WiFi level using level ( in dBm format)
I try lot of google but not get proper ans
Problem with this is that is very dependent on the receiving antenna. Some antennas register no useable signal at -90 dBm, some already at -80. You will have a hard time finding 0% (100% strictly being 0dBm).
I have created a Wifi scanner application where I use -100dBm as 0% and 0dBm as 100%, in Java it turns into something like this (MIN_DBM being -100):
public int getPowerPercentage(int power) {
int i = 0;
if (power <= MIN_DBM) {
i = 0;
} else {
i = 100 + power;
}
return i;
}
This is what Microsoft does for dBm <> percent conversion:
https://stackoverflow.com/a/15798024/2096041
Basically -50 .. 0 dBm maps linear to 100 .. 0 %.
Like MS, i would prefer to sit on the safe side and not use -100 as 100% as some answers here suggest.
The WifiManager class has a function calculateSignalLevel, but as it states here, it results in an error if numLevels is greater than 45. Possible workaround could be something like this:
double percentage = WifiManager.calculateSignalLevel(int rssi, 40) * 2.5;
but of course, this will be in steps of 2.5 percents - I don't know your use case but maybe this is sufficient.
As others have stated, calculating percentages is problematic, and there's no simple precise solution for that.
You could derive the percentage from the signal-to-noise ratio, rather than the signal intensity alone, if this information is available. This is probably the desired metric.
An android.net.wifi.ScanResult does not publish the neccessary information (as of Dec 2012), but you might be able to get this information through other means.
Signal = Noise => unusable signal, so you could set 0dB SnR = 0%. Also you could set 10dB SnR to 90% (90% of the signal power is not drowned out in noise), and 100% = no noise at all. More generally,
p = 100% * (1 - 10^(SnR / (10dB)))
i am looking at the code of a project called MyTracks:
http://code.google.com/r/jrgert-polar-bluetooth/source/browse/MyTracks/src/com/google/android/apps/mytracks/services/sensors/PolarMessageParser.java?r=ebc01faf49550bc9801633ff38bb3b8ddd6f5698
Now I am having problems with the method isValid(byte[] buffer). I don´t understand what exactly is he checking here. We want to know if the first byte in the array is the header containing 0xFE. I don´t quite understand the following lines :
boolean goodHdr = ((buffer[0] & 0xFF) == 0xFE);
boolean goodChk = ((buffer[2] & 0xFF) == (0xFF - (buffer[1] & 0xFF)));
return goodHdr && goodChk;
any ideas?
Ewoks is correct, refer to this blog post:
http://ww.telent.net/2012/5/3/listening_to_a_polar_bluetooth_hrm_in_linux
"Digging into src/com/google/android/apps/mytracks/services/sensors/PolarMessageParser.java we find a helpful comment revealing that, notwithstanding Polar's ridiculous stance on giving out development info (they don't, is the summary) the Wearlink packet format is actually quite simple.
Polar Bluetooth Wearlink packet example
Hdr - Len - Chk - Seq - Status - HeartRate - RRInterval_16-bits
FE - 08 - F7 - 06 - F1 - 48 - 03 64
where
Hdr always = 254 (0xFE),
Chk = 255 - Len
Seq range 0 to 15
Status = Upper nibble may be battery voltage
bit 0 is Beat Detection flag."
&0xff simply converts signed byte to unsigned int for doing the comparison
First line is checking is received buffer are starting with 0xFE as it should be with this Polar Wearable.
Second line is checking if length byte is correct as well because it's value by specification is 255-value writen is size byte..
This together is super simple verification that messages are correct (more complicated implementation would include CRC or other verification methods). cheers
my Android 4 app generates long views by adding multiple textviews to a linearlayout. This works well for all my list items, except of one. The problem is, that the list of textviews aborts after adding the first textview, but no exception is thrown!
I just see this warning in my LogCat:
TextLayoutCache | computeValuesWithHarfbuzz -- need to force to single
run
Does anyone know what that means?
HarfBuzz is a layout/shaping engine for OpenType fonts. Its purpose is to standardize text layout in Open-source projects. That warning, can be traced back to android/graphics/TextLayoutCache.cpp.
The relevant code block is:
ubidi_setPara(bidi, chars, contextCount, bidiReq, NULL, &status); //runs the algorithm
int paraDir = ubidi_getParaLevel(bidi) & kDirection_Mask; // 0 if ltr, 1 if rtl
if (U_SUCCESS(status) && rc == 1) {
// Normal case: one run, status is ok
isRTL = (paraDir == 1);
useSingleRun = true;
} else if (!U_SUCCESS(status) || rc < 1) {
LOGW("computeValuesWithHarfbuzz -- need to force to single run");
isRTL = (paraDir == 1);
useSingleRun = true;
} else {...}
This part of the code is a part of the BiDi algorithm (uBiDi) which stands for Unicode Bidirectional, as detailed here.
Data in Arabic, Hebrew or another RTL languages need handling of bidirectional text. Because these right-to-left scripts use digits that are written from left to right, the text is actually bidirectional: a mixture of right-to-left and left-to-right text.
rc in the above is the runcount of the algorithm. Each unicode character is assigned a level. (Even the unassigned ones)
Text is first split into different levels, (Level 0 is plain English text, Level 1 is plain Arabic text, possibly embedded within English level 0 text, etc)
The runs now occur in the following manner.
Levels: 0 0 0 1 1 1 2
Runs: <--- 1 ---> <--- 2 ---> <3>
Run count in the above example is 3.
The warning is thrown if the BiDi algorithm hasn't been able to run even once successfully. There are many errors that can occur, preventing the successful running of the algorithm.
Any one of these could've triggered the warning.
However, whether the warning occurs or not, the code behaviour is exactly identical except for the warning logged. So, it shouldn't affect the running of the application.