Forums | developer.brewmp.com Forums | developer.brewmp.com

Developer

Forums

Forums:

The newest version of he VX-6000 operating system fixes at least two nasty bugs. If you know of more fixes in this release, please share them with the forum. So far, we've found these two fixes:

1) In VZV05, if your BREW application tried to stay active (or became active) while the clamshell was closed, then LG would paint its wallpaper over your app when the clamshell was opened. If you were displaying scrolling information, you got ugly UI artifacts; the LG wallpaper would appear with your data scrolling through the middle. VZV06 fixes these problems, and now the LG does not paint over your app's UI. If you app is active, it will paint the screen as expected and look quite nice.

2) In some areas of the country (such as the Bay Area) application directed SMS wakeup could throw your phone into an unusable state for about thirty seconds, See my "wacky phone behavior" strand elsewhere in the forum. This no longer occurs in VZV06.

Please add other fixes to this list as you discover them. Also, someone must have the actual comprehensive list; posting that would be very helpful to all of us.

From the google VX-6000 chat site:
Just got my VX-6000 upgraded to SW version 06.
WAP/GIN will now use 1x for data transfer with the new 6000 software. Prior to this, the phone used 14.4 circuit switched CDMA for its internal WAP/GIN, although permitting 1x speeds via data cable. Bottom line is that is should have a speed improvement for GIN and WAP.
In addition to the 1x WAP/GIN, I found an additional fix...text message ringtones now work. In V05 the phone did a low
pitch beep when an SMS arrived, regardles of the custom ringtone that was set.

From the google VX-6000 chat site:
Just got my VX-6000 upgraded to SW version 06.
WAP/GIN will now use 1x for data transfer with the new 6000 software. Prior to this, the phone used 14.4 circuit switched CDMA for its internal WAP/GIN, although permitting 1x speeds via data cable. Bottom line is that is should have a speed improvement for GIN and WAP.
In addition to the 1x WAP/GIN, I found an additional fix...text message ringtones now work. In V05 the phone did a low
pitch beep when an SMS arrived, regardles of the custom ringtone that was set.

Steve, I wanted to thank you for posting this information.
It was helpful to me because I hadn't noticed the difference between 1x and 1xVO phones earlier.
BTW, to anyone else, I believe Steve was referring to http://www.howardforums.com/
--t

Steve, I wanted to thank you for posting this information.
It was helpful to me because I hadn't noticed the difference between 1x and 1xVO phones earlier.
BTW, to anyone else, I believe Steve was referring to http://www.howardforums.com/
--t

It looks like I have a scenario where the VX6000 v06 OS breaks something that was working fine on the VX6000 v05 OS.
My publisher submitted an app to NSTL, and it was rejected because it crashes every time on v06 handsets. v05 handsets work, no problem.
I now have a v06 handset in front of me and am attempting to track down the problem, so I stuck in a little chunk of debug code that opens up a debug file that I can write text out to to help me figure out where things are going wrong.
The funny thing is that my debug code (snippet below) doesn't even seem to work on the v06 handset - but it works just fine on v05! After definitely hitting code sections where some debug should be written to the debug file, I'd end up with a file on the v06 handset that had zero bytes in it. Furthermore, I can't even download this zero byte file from the phone (just a test), as apploader v2.1.1.3 fails with the message "Error - could not read file from the device." If I take this exact .mif, .mod and .bar and load in onto a v05 handset, it works like a champ. I thought that maybe I had a .mif without file write permissions set, but this is not the case.
Here's how I open, write to, and close my debug file:
// Create an instance of the file manager
if(ISHELL_CreateInstance(capp->pShell, AEECLSID_FILEMGR, (void **)&(pfilemgr)) != SUCCESS)
return;
// Create the debug file
capp->debugfile = IFILEMGR_OpenFile(pfilemgr, "DEBUGJ.TXT", _OFM_CREATE);
// Write some stuff to the debug file
SPRINTF(GetApp()->charbuf, "This is a test\r\n");
IFILE_Write(GetApp()->debugfile, (void *)(GetApp()->charbuf), STRLEN(GetApp()->charbuf));
// Close the debug file
if(capp->debugfile) IFILE_Release(capp->debugfile);
Has anybody had any strange problems with the v06 VX6000, and does anybody have any suggestions as to what might be going on here? Since I can't get my debug code working, I can't even get to the real issue: figuring out where and why my publishers app crashes on the VX6000 with v06 OS.
Thanks

It looks like I have a scenario where the VX6000 v06 OS breaks something that was working fine on the VX6000 v05 OS.
My publisher submitted an app to NSTL, and it was rejected because it crashes every time on v06 handsets. v05 handsets work, no problem.
I now have a v06 handset in front of me and am attempting to track down the problem, so I stuck in a little chunk of debug code that opens up a debug file that I can write text out to to help me figure out where things are going wrong.
The funny thing is that my debug code (snippet below) doesn't even seem to work on the v06 handset - but it works just fine on v05! After definitely hitting code sections where some debug should be written to the debug file, I'd end up with a file on the v06 handset that had zero bytes in it. Furthermore, I can't even download this zero byte file from the phone (just a test), as apploader v2.1.1.3 fails with the message "Error - could not read file from the device." If I take this exact .mif, .mod and .bar and load in onto a v05 handset, it works like a champ. I thought that maybe I had a .mif without file write permissions set, but this is not the case.
Here's how I open, write to, and close my debug file:
// Create an instance of the file manager
if(ISHELL_CreateInstance(capp->pShell, AEECLSID_FILEMGR, (void **)&(pfilemgr)) != SUCCESS)
return;
// Create the debug file
capp->debugfile = IFILEMGR_OpenFile(pfilemgr, "DEBUGJ.TXT", _OFM_CREATE);
// Write some stuff to the debug file
SPRINTF(GetApp()->charbuf, "This is a test\r\n");
IFILE_Write(GetApp()->debugfile, (void *)(GetApp()->charbuf), STRLEN(GetApp()->charbuf));
// Close the debug file
if(capp->debugfile) IFILE_Release(capp->debugfile);
Has anybody had any strange problems with the v06 VX6000, and does anybody have any suggestions as to what might be going on here? Since I can't get my debug code working, I can't even get to the real issue: figuring out where and why my publishers app crashes on the VX6000 with v06 OS.
Thanks

A testing update: just to absolutely make sure that the code was where I thought it was running, I stuck an endless loop while(1) after my IFILE_Write() call. Sure enough, the phone locked up, I had to pop the battery to reset it, and when it came back up...there's a debug file waiting with text written to it - just like I thought there should be.
Could this be something weird with file caching on the VX6000 with the new v06 OS?

A testing update: just to absolutely make sure that the code was where I thought it was running, I stuck an endless loop while(1) after my IFILE_Write() call. Sure enough, the phone locked up, I had to pop the battery to reset it, and when it came back up...there's a debug file waiting with text written to it - just like I thought there should be.
Could this be something weird with file caching on the VX6000 with the new v06 OS?

More info:
I added this code to my debug test:
numwritten = IFILE_Write(GetApp()->debugfile, (void *)(GetApp()->charbuf), STRLEN(GetApp()->charbuf));
if(numwritten)
{
while(1);

Results:
v05 handset: locks up, have to pop battery to reset it.
v06 handset: continues running, proving to me that numwritten=0, and thus, that the IFILE_Write() is failing.
Anybody?

More info:
I added this code to my debug test:
numwritten = IFILE_Write(GetApp()->debugfile, (void *)(GetApp()->charbuf), STRLEN(GetApp()->charbuf));
if(numwritten)
{
while(1);

Results:
v05 handset: locks up, have to pop battery to reset it.
v06 handset: continues running, proving to me that numwritten=0, and thus, that the IFILE_Write() is failing.
Anybody?

Quote:Originally posted by John Jacecko
I now have a v06 handset in front of me and am attempting to track down the problem, so I stuck in a little chunk of debug code that opens up a debug file that I can write text out to to help me figure out where things are going wrong.I've been logging debug statements to a file on v06 VX6000 handsets. The only problems I've had with it were my own bugs. Or when I tried to write too much to it at once.
Quote:After definitely hitting code sections where some debug should be written to the debug file, I'd end up with a file on the v06 handset that had zero bytes in it.I have seen this before when trying to write out a binary cache file. I haven't fully debugged the problem. I don't have a v05 handset to compare to, but if I really needed it I'd have to get it working on v06 no matter what so I guess it doesn't really matter what v05 does. I know the log file works, so the cache file should work too.
About the code, add some more error checking... and display something different for diff errors. Also you're creating the file -- if you don't delete it each time, check if it exists first, then use _OFM_APPEND or whatever. Maybe v05 is more forgiving about this. Obviously all this file handling should be in a separate module.
// Create an instance of the file manager
if(ISHELL_CreateInstance(capp->pShell, AEECLSID_FILEMGR,
(void **)&(pfilemgr)) != SUCCESS)
return;
// Create the debug file
if (pfilemgr) {
capp->debugfile = IFILEMGR_OpenFile(pfilemgr, "DEBUGJ.TXT",
_OFM_CREATE);
if (capp->debugfile) {
// Write some stuff to the debug file
SPRINTF(GetApp()->charbuf, "This is a test\r\n");
int nWritten = IFILE_Write(GetApp()->debugfile,
(void *)(GetApp()->charbuf), STRLEN(GetApp()->charbuf));
// Close the debug file
IFILE_Release(capp->debugfile);
if (!nWritten) {
PutBigBlueRectOnScreen(GetApp()->m_pIDisplay);
IDISPLAY_UpdateEx(GetApp()->m_pIDisplay,FALSE);
}
}
else {
PutBigRedRectOnScreen(GetApp()->m_pIDisplay);
IDISPLAY_UpdateEx(GetApp()->m_pIDisplay,FALSE);
}
IFILEMGR_Release(pfilemgr);

Quote:Originally posted by John Jacecko
I now have a v06 handset in front of me and am attempting to track down the problem, so I stuck in a little chunk of debug code that opens up a debug file that I can write text out to to help me figure out where things are going wrong.I've been logging debug statements to a file on v06 VX6000 handsets. The only problems I've had with it were my own bugs. Or when I tried to write too much to it at once.
Quote:After definitely hitting code sections where some debug should be written to the debug file, I'd end up with a file on the v06 handset that had zero bytes in it.I have seen this before when trying to write out a binary cache file. I haven't fully debugged the problem. I don't have a v05 handset to compare to, but if I really needed it I'd have to get it working on v06 no matter what so I guess it doesn't really matter what v05 does. I know the log file works, so the cache file should work too.
About the code, add some more error checking... and display something different for diff errors. Also you're creating the file -- if you don't delete it each time, check if it exists first, then use _OFM_APPEND or whatever. Maybe v05 is more forgiving about this. Obviously all this file handling should be in a separate module.
// Create an instance of the file manager
if(ISHELL_CreateInstance(capp->pShell, AEECLSID_FILEMGR,
(void **)&(pfilemgr)) != SUCCESS)
return;
// Create the debug file
if (pfilemgr) {
capp->debugfile = IFILEMGR_OpenFile(pfilemgr, "DEBUGJ.TXT",
_OFM_CREATE);
if (capp->debugfile) {
// Write some stuff to the debug file
SPRINTF(GetApp()->charbuf, "This is a test\r\n");
int nWritten = IFILE_Write(GetApp()->debugfile,
(void *)(GetApp()->charbuf), STRLEN(GetApp()->charbuf));
// Close the debug file
IFILE_Release(capp->debugfile);
if (!nWritten) {
PutBigBlueRectOnScreen(GetApp()->m_pIDisplay);
IDISPLAY_UpdateEx(GetApp()->m_pIDisplay,FALSE);
}
}
else {
PutBigRedRectOnScreen(GetApp()->m_pIDisplay);
IDISPLAY_UpdateEx(GetApp()->m_pIDisplay,FALSE);
}
IFILEMGR_Release(pfilemgr);

Thanks for the tips, Tom. I don't think that I'm messing anything up with my debug logging routines or writing too much out, but hey - stranger things have happened. My debug logging routines currently open up the log file once and leave it open while the app is active, then close it once when the app is terminated, with writes to the file inbetween. I'll re-write my routine to make it open, create or append, write and then close the file each time I want to write out some debug info.

Thanks for the tips, Tom. I don't think that I'm messing anything up with my debug logging routines or writing too much out, but hey - stranger things have happened. My debug logging routines currently open up the log file once and leave it open while the app is active, then close it once when the app is terminated, with writes to the file inbetween. I'll re-write my routine to make it open, create or append, write and then close the file each time I want to write out some debug info.

Sorry about being pedantic. I had been working with someone's code that had no error checking in it not too long ago, and so it was a hot button for me.
I originally made my logging class open and close the file every time it wrote, just to make sure it flushed the write buffer, but since then have removed that. Even when the app crashes or resets the handset, it seems to write everything out anyway.
I'm pretty sure the BREW file lib doesn't have any buffering because when you run it in the emulator, you can actually hear the hard drive whacking away to write the log file. I try to log as little as possible.
Anyway, you should be able to log to file on a v06 vx6000.

Sorry about being pedantic. I had been working with someone's code that had no error checking in it not too long ago, and so it was a hot button for me.
I originally made my logging class open and close the file every time it wrote, just to make sure it flushed the write buffer, but since then have removed that. Even when the app crashes or resets the handset, it seems to write everything out anyway.
I'm pretty sure the BREW file lib doesn't have any buffering because when you run it in the emulator, you can actually hear the hard drive whacking away to write the log file. I try to log as little as possible.
Anyway, you should be able to log to file on a v06 vx6000.

No problem. I left out the details, so you had no way of knowing! I have to split for a few hours, so I'll post my findings after I get back and work on this some more. A quick question: Can you or do you have to specify the type of file you want to open, i.e. binary or text, like with fopen() in C?

No problem. I left out the details, so you had no way of knowing! I have to split for a few hours, so I'll post my findings after I get back and work on this some more. A quick question: Can you or do you have to specify the type of file you want to open, i.e. binary or text, like with fopen() in C?

Call back the hounds. It's another case of Occham's Razor.
I'm sitting here scratching my head, thinking what, besides the OS version, is different about my v05 handset compared to my v06 handset. Then it hit me: the v06 phone has a ton of apps loaded onto it. I checked the BREW settings->manage apps menu, and sure enough, it reported 0k available. So I deleted one app to clear some space, and viola, my debug logging code works like a champ! So the file system could create the file, but it couldn't write a single byte to it...
At least now I can go and hunt for the real problem - why the handset crashes when the front end tries to launch the game. Sweet...

Call back the hounds. It's another case of Occham's Razor.
I'm sitting here scratching my head, thinking what, besides the OS version, is different about my v05 handset compared to my v06 handset. Then it hit me: the v06 phone has a ton of apps loaded onto it. I checked the BREW settings->manage apps menu, and sure enough, it reported 0k available. So I deleted one app to clear some space, and viola, my debug logging code works like a champ! So the file system could create the file, but it couldn't write a single byte to it...
At least now I can go and hunt for the real problem - why the handset crashes when the front end tries to launch the game. Sweet...

Steve,
Thank you for posting info about the software upgrade. We had to remove some features from our app because of the "6000 painting wallpaper when the clamshell is closed' bug.
So, the question is, can we resubmit our apps just for these newer handsets? Will Qaulcomm/Carreirs provision them differently?
even if they did, I think it would be stupid on us to submit it that way, because, then it would be difficult to market our product. We will have to say, if you purchased your handset after this date, you will have this feature if not you won't have this feature.
May be they should have changed the model number to something like 6001.
-Vasanth

Steve,
Thank you for posting info about the software upgrade. We had to remove some features from our app because of the "6000 painting wallpaper when the clamshell is closed' bug.
So, the question is, can we resubmit our apps just for these newer handsets? Will Qaulcomm/Carreirs provision them differently?
even if they did, I think it would be stupid on us to submit it that way, because, then it would be difficult to market our product. We will have to say, if you purchased your handset after this date, you will have this feature if not you won't have this feature.
May be they should have changed the model number to something like 6001.
-Vasanth

I don't know, Vasanth. We're going to ensure that our customers have the newest VZV OS version on their handset before getting our app, but we're lucky in the sense that we can control that for now. We'll have to see what NSTL says for your case.

I don't know, Vasanth. We're going to ensure that our customers have the newest VZV OS version on their handset before getting our app, but we're lucky in the sense that we can control that for now. We'll have to see what NSTL says for your case.

In case it helps you, I've come up with a hacky way of determining the OS version of the VX6000 your app is running on. With this knowledge, you could selectively enable/disable featues of your app, depending on the OS version of the handset.
Check out this thread, and if you're interested, let me know and I'll give you more details:
http://brewforums.qualcomm.com/showthread.php?s=&threadid=3777

In case it helps you, I've come up with a hacky way of determining the OS version of the VX6000 your app is running on. With this knowledge, you could selectively enable/disable featues of your app, depending on the OS version of the handset.
Check out this thread, and if you're interested, let me know and I'll give you more details:
http://brewforums.qualcomm.com/showthread.php?s=&threadid=3777

Hey have any of you noticed problems with INETMGR_GetHostByName in v05? I don't have a v05 VX6000 to test on.
I tried an app on v02 and the DNS fails, but it works fine on v06. I wrote about this here: http://brewforums.qualcomm.com/showthread.php?s=&threadid=3821
Verizon stores can only flash a phone to the latest version (v06). Maybe Qualcomm can flash it to an older version....

Hey have any of you noticed problems with INETMGR_GetHostByName in v05? I don't have a v05 VX6000 to test on.
I tried an app on v02 and the DNS fails, but it works fine on v06. I wrote about this here: http://brewforums.qualcomm.com/showthread.php?s=&threadid=3821
Verizon stores can only flash a phone to the latest version (v06). Maybe Qualcomm can flash it to an older version....

I have tried it on v05 handsets and it does work.
-Vasanth

I have tried it on v05 handsets and it does work.
-Vasanth

Thanks Vasanth!

Thanks Vasanth!