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

Developer

Forums

Forums:

Hi Max,

We have a device-specific issue with the Curitel / Audiovox CDM-8940.

When the clamshell is closed while an app is running, then the app receives a EVT_FLIP. If the app exits in response to this event, when the clamshell is opened, the handset is displaying the Get-It-Now screen, not the OEM screen.

We have been told by NSTL that this will fail TBT, even if it is documented in section 7 of the App Spec. They insist that it must exit to the OEM screen.

I don't understand NSTL's position here. The app exits in response to EVT_FLIP and is documented in the App Spec. The AUT is complying to the requirements described here: http://brewforums.qualcomm.com/showthread.php?t=6190

This is clearly a device-specific issue that has nothing to do with the app. You can even prove this by going to the Get-It-Now screen, and closing the clamshell. When it is reopened, then the handset is still displaying the Get-It-Now screen. All other BREW handsets will display the OEM screen, including the VX8000.

Is it possible for you to mark this as a known issue for the 8940?

What is necessary for me to prove my case?
Thanks,
Tom

Have you tried calling ISHELL_CloseApplet(x, TRUE) in response to the flip event? When I can get my hands on a phone, I'll test it out.

Have you tried calling ISHELL_CloseApplet(x, TRUE) in response to the flip event? When I can get my hands on a phone, I'll test it out.

I don't understand why NSTL has to test this, its rarely the same twice, same for exit, some phones go to the home screen, some go to the Get It Now screen, they should just stop testing for it. Almost all phones don't do what the NSTL test documents say it should in regards to which screen it returns too ,we've posted about this on the boards and to NSTL before and its not been changed.

I don't understand why NSTL has to test this, its rarely the same twice, same for exit, some phones go to the home screen, some go to the Get It Now screen, they should just stop testing for it. Almost all phones don't do what the NSTL test documents say it should in regards to which screen it returns too ,we've posted about this on the boards and to NSTL before and its not been changed.

OK, I got back a little while ago, and read a message that NSTL says that ISHELL_CloseApplet(pIShell, TRUE) should work properly on BREW 2.1 handsets.
So I just tried it, and it does behave differently: It locks up this handset, requiring the battery to be pulled.
Just in case it was something weird caused by this game, I wrote a minimal app (in C, yuck, no less) which does nothing but call ISHELL_CloseApplet(pIShell, TRUE) in response to an EVT_FLIP. When the clamshell is closed, it also locks up the handset.
By "locks up", I mean that the screen is blank and it is unresponsive to keypresses. However, AppLoader can access the file system.
It's possible that this behavior occurs only on pre-release handsets, but that's all we have here.
SW: D160VE3T03_6.168
HW: TX-160C_REV_03
Is this sufficient proof that the 8940 has a known issue?
I have uploaded the test app with full source, in case anyone wants to give it a try on a handset. I tried the app on a different Audiovox, the CDM-8910, and it works fine.
--t

OK, I got back a little while ago, and read a message that NSTL says that ISHELL_CloseApplet(pIShell, TRUE) should work properly on BREW 2.1 handsets.
So I just tried it, and it does behave differently: It locks up this handset, requiring the battery to be pulled.
Just in case it was something weird caused by this game, I wrote a minimal app (in C, yuck, no less) which does nothing but call ISHELL_CloseApplet(pIShell, TRUE) in response to an EVT_FLIP. When the clamshell is closed, it also locks up the handset.
By "locks up", I mean that the screen is blank and it is unresponsive to keypresses. However, AppLoader can access the file system.
It's possible that this behavior occurs only on pre-release handsets, but that's all we have here.
SW: D160VE3T03_6.168
HW: TX-160C_REV_03
Is this sufficient proof that the 8940 has a known issue?
I have uploaded the test app with full source, in case anyone wants to give it a try on a handset. I tried the app on a different Audiovox, the CDM-8910, and it works fine.
--t

tom wrote:OK, I got back a little while ago, and read a message that NSTL says that ISHELL_CloseApplet(pIShell, TRUE) should work properly on BREW 2.1 handsets.
So I just tried it, and it does behave differently: It locks up this handset, requiring the battery to be pulled.
Just in case it was something weird caused by this game, I wrote a minimal app (in C, yuck, no less) which does nothing but call ISHELL_CloseApplet(pIShell, TRUE) in response to an EVT_FLIP. When the clamshell is closed, it also locks up the handset.
By "locks up", I mean that the screen is blank and it is unresponsive to keypresses. However, AppLoader can access the file system.
It's possible that this behavior occurs only on pre-release handsets, but that's all we have here.
SW: D160VE3T03_6.168
HW: TX-160C_REV_03
Is this sufficient proof that the 8940 has a known issue?
I have uploaded the test app with full source, in case anyone wants to give it a try on a handset. I tried the app on a different Audiovox, the CDM-8910, and it works fine.
--t
Have you tried it without the logfile append before the close?
Perhaps there is a file IO timing issue here.

tom wrote:OK, I got back a little while ago, and read a message that NSTL says that ISHELL_CloseApplet(pIShell, TRUE) should work properly on BREW 2.1 handsets.
So I just tried it, and it does behave differently: It locks up this handset, requiring the battery to be pulled.
Just in case it was something weird caused by this game, I wrote a minimal app (in C, yuck, no less) which does nothing but call ISHELL_CloseApplet(pIShell, TRUE) in response to an EVT_FLIP. When the clamshell is closed, it also locks up the handset.
By "locks up", I mean that the screen is blank and it is unresponsive to keypresses. However, AppLoader can access the file system.
It's possible that this behavior occurs only on pre-release handsets, but that's all we have here.
SW: D160VE3T03_6.168
HW: TX-160C_REV_03
Is this sufficient proof that the 8940 has a known issue?
I have uploaded the test app with full source, in case anyone wants to give it a try on a handset. I tried the app on a different Audiovox, the CDM-8910, and it works fine.
--t
Have you tried it without the logfile append before the close?
Perhaps there is a file IO timing issue here.

Yes, I added the logfile after finding out that closing the clamshell locked up the handset.
It'd be such a fun handset if that were truly the problem, as I've seen plenty of other AAA titles that also close a file handle upon shutdown.
But okay, here's an even more minimal app. No logfile. It also locks up the 8940 when the clamshell is closed.
[edit: BTW Jim, thanks for taking the time to look at it and give feedback. --t]

Yes, I added the logfile after finding out that closing the clamshell locked up the handset.
It'd be such a fun handset if that were truly the problem, as I've seen plenty of other AAA titles that also close a file handle upon shutdown.
But okay, here's an even more minimal app. No logfile. It also locks up the 8940 when the clamshell is closed.
[edit: BTW Jim, thanks for taking the time to look at it and give feedback. --t]

tom wrote:Yes, I added the logfile after finding out that closing the clamshell locked up the handset.
It'd be such a fun handset if that were truly the problem, as I've seen plenty of other AAA titles that also close a file handle upon shutdown.
But okay, here's an even more minimal app. No logfile. It also locks up the 8940 when the clamshell is closed.
[edit: BTW Jim, thanks for taking the time to look at it and give feedback. --t]
I guesss the next thing I would try as a workaround is to set a timer on the flip and close the app when the timer hits. IOW give it a little bit of time after the flip message and then close the app. Perhaps 250 ms? Should not be noticable.
---jeff

tom wrote:Yes, I added the logfile after finding out that closing the clamshell locked up the handset.
It'd be such a fun handset if that were truly the problem, as I've seen plenty of other AAA titles that also close a file handle upon shutdown.
But okay, here's an even more minimal app. No logfile. It also locks up the 8940 when the clamshell is closed.
[edit: BTW Jim, thanks for taking the time to look at it and give feedback. --t]
I guesss the next thing I would try as a workaround is to set a timer on the flip and close the app when the timer hits. IOW give it a little bit of time after the flip message and then close the app. Perhaps 250 ms? Should not be noticable.
---jeff

Wow, are you kidding me? I've never heard of this workaround.
OK, I don't have time right now, but will try it later tonight. Thanks for your help Jeff!! Sorry I thought your name was Jim for some reason.
--t

Wow, are you kidding me? I've never heard of this workaround.
OK, I don't have time right now, but will try it later tonight. Thanks for your help Jeff!! Sorry I thought your name was Jim for some reason.
--t

tom wrote:Wow, are you kidding me? I've never heard of this workaround.
OK, I don't have time right now, but will try it later tonight. Thanks for your help Jeff!! Sorry I thought your name was Jim for some reason.
--t
I am not touting it -- just suggesting it.
There was a similar workaround to replaying sound.
(i.e. wait a bit before re-playing after first clip ends)
My thought is that what is going on is that a thread has
not yet cleaned up (not yours but one in the firmware or
elsewhere beyond the developers control), and that given
a small amount of time for things to synch up, your close
would not cause an issue.
If this is NOT the case, then I would suspect most any app close to
fail after a close-open cycle. If it doesn't then there must logically
be a workaround. If it does then there is a much bigger problem.
If the fix is as simple as setting a timer to close the app then you
can have the same code work accross multiple handsets.

tom wrote:Wow, are you kidding me? I've never heard of this workaround.
OK, I don't have time right now, but will try it later tonight. Thanks for your help Jeff!! Sorry I thought your name was Jim for some reason.
--t
I am not touting it -- just suggesting it.
There was a similar workaround to replaying sound.
(i.e. wait a bit before re-playing after first clip ends)
My thought is that what is going on is that a thread has
not yet cleaned up (not yours but one in the firmware or
elsewhere beyond the developers control), and that given
a small amount of time for things to synch up, your close
would not cause an issue.
If this is NOT the case, then I would suspect most any app close to
fail after a close-open cycle. If it doesn't then there must logically
be a workaround. If it does then there is a much bigger problem.
If the fix is as simple as setting a timer to close the app then you
can have the same code work accross multiple handsets.

Ok, looks like an issue...I'll get the wheels spinning.

Ok, looks like an issue...I'll get the wheels spinning.

Thanks Max, I appreciate that!
Thanks Jeff, for the suggestion. It's a good line of investigation, but I just tried it at 250ms and it didn't work. Same behavior.
--t

Thanks Max, I appreciate that!
Thanks Jeff, for the suggestion. It's a good line of investigation, but I just tried it at 250ms and it didn't work. Same behavior.
--t

tom wrote:Thanks Max, I appreciate that!
Thanks Jeff, for the suggestion. It's a good line of investigation, but I just tried it at 250ms and it didn't work. Same behavior.
--t
What is the behavior if you dont respond to the flip
message at all? Does your app still crash when you close it?

tom wrote:Thanks Max, I appreciate that!
Thanks Jeff, for the suggestion. It's a good line of investigation, but I just tried it at 250ms and it didn't work. Same behavior.
--t
What is the behavior if you dont respond to the flip
message at all? Does your app still crash when you close it?

jmiller2 wrote:What is the behavior if you dont respond to the flip
message at all? Does your app still crash when you close it?No, the crash only occurs if you do ISHELL_CloseApplet(pIShell, TRUE) in response to EVT_FLIP.
If you do ISHELL_CloseApplet(pIShell, FALSE) then it exits to the BREW / G-I-N screen.
NSTL is saying that we should be able to set bReturnToIdle to TRUE in order to return to the OEM screen.
--t

jmiller2 wrote:What is the behavior if you dont respond to the flip
message at all? Does your app still crash when you close it?No, the crash only occurs if you do ISHELL_CloseApplet(pIShell, TRUE) in response to EVT_FLIP.
If you do ISHELL_CloseApplet(pIShell, FALSE) then it exits to the BREW / G-I-N screen.
NSTL is saying that we should be able to set bReturnToIdle to TRUE in order to return to the OEM screen.
--t

tom wrote:No, the crash only occurs if you do ISHELL_CloseApplet(pIShell, TRUE) in response to EVT_FLIP.
If you do ISHELL_CloseApplet(pIShell, FALSE) then it exits to the BREW / G-I-N screen.
NSTL is saying that we should be able to set bReturnToIdle to TRUE in order to return to the OEM screen.
--t
Hmm, then I am lost as to why setting a timer would not
be esentially the same as flipping closed, then open, then
closing the app....
Oh well...

tom wrote:No, the crash only occurs if you do ISHELL_CloseApplet(pIShell, TRUE) in response to EVT_FLIP.
If you do ISHELL_CloseApplet(pIShell, FALSE) then it exits to the BREW / G-I-N screen.
NSTL is saying that we should be able to set bReturnToIdle to TRUE in order to return to the OEM screen.
--t
Hmm, then I am lost as to why setting a timer would not
be esentially the same as flipping closed, then open, then
closing the app....
Oh well...

BREW Support verified this issue today.
We also discovered another crash problem if you follow the procedure described for CR#26490 listed in the known issues for the CDM-9900.
--t

BREW Support verified this issue today.
We also discovered another crash problem if you follow the procedure described for CR#26490 listed in the known issues for the CDM-9900.
--t

Tom, yea I have the same problem with ISHELL_CloseApplet(...) @ EVT_FLIP.
sw: 0160ve3t03_6.168
hw: tx-160c_rev_03
gin: 2.1.3.8
What's really strange is that ISHELL_CloseApplet(pShell, TRUE) outside of an EVT_FLIP case works fine. :confused:

Tom, yea I have the same problem with ISHELL_CloseApplet(...) @ EVT_FLIP.
sw: 0160ve3t03_6.168
hw: tx-160c_rev_03
gin: 2.1.3.8
What's really strange is that ISHELL_CloseApplet(pShell, TRUE) outside of an EVT_FLIP case works fine. :confused:

Here's a workaround so NSTL won't fail us:
case EVT_FLIP:
... if (pme->iFlips++) ISHELL_CloseApplet(...,TRUE);
case EVT_APP_START: //or in your init() func
... pme->iFlips=0;
It seems the phone only crashes when the clam is closed... so if you only run CloseApplet(TRUE) when user has reopened the clam, it won't crash.

Here's a workaround so NSTL won't fail us:
case EVT_FLIP:
... if (pme->iFlips++) ISHELL_CloseApplet(...,TRUE);
case EVT_APP_START: //or in your init() func
... pme->iFlips=0;
It seems the phone only crashes when the clam is closed... so if you only run CloseApplet(TRUE) when user has reopened the clam, it won't crash.

ant wrote:Here's a workaround so NSTL won't fail us:
case EVT_FLIP:
... if (pme->iFlips++) ISHELL_CloseApplet(...,TRUE);
case EVT_APP_START: //or in your init() func
... pme->iFlips=0;
It seems the phone only crashes when the clam is closed... so if you only run CloseApplet(TRUE) when user has reopened the clam, it won't crash.Nice!!! Thanks Ant! I guess that would have been the next step after trying Jeff's suggestion, but I gave up too soon. Good one.
--t

ant wrote:Here's a workaround so NSTL won't fail us:
case EVT_FLIP:
... if (pme->iFlips++) ISHELL_CloseApplet(...,TRUE);
case EVT_APP_START: //or in your init() func
... pme->iFlips=0;
It seems the phone only crashes when the clam is closed... so if you only run CloseApplet(TRUE) when user has reopened the clam, it won't crash.Nice!!! Thanks Ant! I guess that would have been the next step after trying Jeff's suggestion, but I gave up too soon. Good one.
--t

This isn't really satisfying the requirements...the intent is that the application stops running once the clamshell is closed. While it will probably get through testing, I'd recommend that you not rely on this procedure.
Also, you can just check the wParam for the EVT_FLIP to see if it's TRUE - this indicates the clamshell is open.

This isn't really satisfying the requirements...the intent is that the application stops running once the clamshell is closed. While it will probably get through testing, I'd recommend that you not rely on this procedure.
Also, you can just check the wParam for the EVT_FLIP to see if it's TRUE - this indicates the clamshell is open.

Hi Max,
has NSTL confirmed that this is a device issue and won't fail the app for this? if not, do you have the work-around that meets the TRUE BREW test requirement?
Thanks,
Jean

Hi Max,
has NSTL confirmed that this is a device issue and won't fail the app for this? if not, do you have the work-around that meets the TRUE BREW test requirement?
Thanks,
Jean

The OEM fixed this problem in the most recent software build - calling ISHELL_CloseApplet() no longer causes problems.

The OEM fixed this problem in the most recent software build - calling ISHELL_CloseApplet() no longer causes problems.

so, with the most recent FW build of CDM8940, below would just work and NSTL won't fail it? or I need to do "ISHELL_CloseApplet(pme->a.m_pIShell,TRUE)" ?
*****************************************
case EVT_FLIP:
ISHELL_CloseApplet(pme->a.m_pIShell,FALSE);
return TRUE;
*****************************************
p.s. is 3.172 the most recent FW build of CDM8940?
Thanks,
Jean

so, with the most recent FW build of CDM8940, below would just work and NSTL won't fail it? or I need to do "ISHELL_CloseApplet(pme->a.m_pIShell,TRUE)" ?
*****************************************
case EVT_FLIP:
ISHELL_CloseApplet(pme->a.m_pIShell,FALSE);
return TRUE;
*****************************************
p.s. is 3.172 the most recent FW build of CDM8940?
Thanks,
Jean

Yes, I'm referring to 3.172. To return the user to the native idle screen, you need to call ISHELL_CloseApplet(pIShell, TRUE). Passing FALSE will not exit from App Manager. This whole TBT requirement may be revised at some point, as BREW 3.1+ requires PL_SYSTEM privilege level to call ISHELL_CloseApplet(pIShell, TRUE).

Yes, I'm referring to 3.172. To return the user to the native idle screen, you need to call ISHELL_CloseApplet(pIShell, TRUE). Passing FALSE will not exit from App Manager. This whole TBT requirement may be revised at some point, as BREW 3.1+ requires PL_SYSTEM privilege level to call ISHELL_CloseApplet(pIShell, TRUE).

Does anyone know if the newest version of the CDM8940 firmware fixes the issue of the RIGHT SOFTKEY returning a AVK_UNDEFINED keycode?

Does anyone know if the newest version of the CDM8940 firmware fixes the issue of the RIGHT SOFTKEY returning a AVK_UNDEFINED keycode?

Yes, that has been addressed as well.

Yes, that has been addressed as well.

This whole EVT_FLIP issue is confusing. We use the FALSE like below and our app passed, but now, we have people drumming for it to be TRUE or it will fail TBT.
Max, I know you have responded before, but can you paste the code TBT expects? If push come to shove, I will stick the code sample to NSTL.
:D
jeantsai wrote:so, with the most recent FW build of CDM8940, below would just work and NSTL won't fail it? or I need to do "ISHELL_CloseApplet(pme->a.m_pIShell,TRUE)" ?
*****************************************
case EVT_FLIP:
ISHELL_CloseApplet(pme->a.m_pIShell,FALSE);
return TRUE;
*****************************************
p.s. is 3.172 the most recent FW build of CDM8940?
Thanks,
Jean

This whole EVT_FLIP issue is confusing. We use the FALSE like below and our app passed, but now, we have people drumming for it to be TRUE or it will fail TBT.
Max, I know you have responded before, but can you paste the code TBT expects? If push come to shove, I will stick the code sample to NSTL.
:D
jeantsai wrote:so, with the most recent FW build of CDM8940, below would just work and NSTL won't fail it? or I need to do "ISHELL_CloseApplet(pme->a.m_pIShell,TRUE)" ?
*****************************************
case EVT_FLIP:
ISHELL_CloseApplet(pme->a.m_pIShell,FALSE);
return TRUE;
*****************************************
p.s. is 3.172 the most recent FW build of CDM8940?
Thanks,
Jean

NSTL is expecting something like this:
case EVT_FLIP:
if(!wParam) // only exit on clamshell close
ISHELL_CloseApplet(pme->a.m_pIShell, TRUE);
return TRUE;
This is a bad requirement for the reason I mentioned above, but it probably won't be changing any time in the near future.

NSTL is expecting something like this:
case EVT_FLIP:
if(!wParam) // only exit on clamshell close
ISHELL_CloseApplet(pme->a.m_pIShell, TRUE);
return TRUE;
This is a bad requirement for the reason I mentioned above, but it probably won't be changing any time in the near future.

this is work-around for CDM8940 only or it is what's supposed to be done in all other handsets?
Thanks,
Jean

this is work-around for CDM8940 only or it is what's supposed to be done in all other handsets?
Thanks,
Jean

That's supposedly the generic case.

That's supposedly the generic case.

the API reference doc says "ISHELL_CloseApplet(pme->a.m_pIShell, TRUE);" would close ALL OTHER active applications,
so this is what we should do in all handsets when clamshell is closed at the moment our app is running? would there be any side effect?
Thanks,
Jean

the API reference doc says "ISHELL_CloseApplet(pme->a.m_pIShell, TRUE);" would close ALL OTHER active applications,
so this is what we should do in all handsets when clamshell is closed at the moment our app is running? would there be any side effect?
Thanks,
Jean

jeantsai wrote:the API reference doc says "ISHELL_CloseApplet(pme->a.m_pIShell, TRUE);" would close ALL OTHER active applications,
so this is what we should do in all handsets when clamshell is closed at the moment our app is running? would there be any side effect?
Thanks,
Jean
Yes, this is why the call requires PL_SYSTEM in newer versions of BREW. The side effect would be that other active applications are terminated.

jeantsai wrote:the API reference doc says "ISHELL_CloseApplet(pme->a.m_pIShell, TRUE);" would close ALL OTHER active applications,
so this is what we should do in all handsets when clamshell is closed at the moment our app is running? would there be any side effect?
Thanks,
Jean
Yes, this is why the call requires PL_SYSTEM in newer versions of BREW. The side effect would be that other active applications are terminated.

mohlendo wrote:NSTL is expecting something like this:
case EVT_FLIP:
if(!wParam) // only exit on clamshell close
ISHELL_CloseApplet(pme->a.m_pIShell, TRUE);
return TRUE;
This is a bad requirement for the reason I mentioned above, but it probably won't be changing any time in the near future.
Couple of questions:
1. re: "if(!wParam) // only exit on clamshell close"
How would it be possible to get the clamshell Open without
a previous close? IOW what is the point of testing wParam?
2. re: "This is a bad requirement for the reason I mentioned above, but it probably won't be changing any time in the near future"
So if Qualcomm recognizes that something is a bad requirement they
cannot specify that NSTL changes it??!!
I did,
ISHELL_CloseApplet(pMe->a.m_pIShell, FALSE);
and the app passed. I cannot fathom why we would need to call
ISHELL_CloseApplet(pMe->a.m_pIShell, TRUE);
but if that is what you want from now on then I will mod my base class
code to do it as you have specified above.

mohlendo wrote:NSTL is expecting something like this:
case EVT_FLIP:
if(!wParam) // only exit on clamshell close
ISHELL_CloseApplet(pme->a.m_pIShell, TRUE);
return TRUE;
This is a bad requirement for the reason I mentioned above, but it probably won't be changing any time in the near future.
Couple of questions:
1. re: "if(!wParam) // only exit on clamshell close"
How would it be possible to get the clamshell Open without
a previous close? IOW what is the point of testing wParam?
2. re: "This is a bad requirement for the reason I mentioned above, but it probably won't be changing any time in the near future"
So if Qualcomm recognizes that something is a bad requirement they
cannot specify that NSTL changes it??!!
I did,
ISHELL_CloseApplet(pMe->a.m_pIShell, FALSE);
and the app passed. I cannot fathom why we would need to call
ISHELL_CloseApplet(pMe->a.m_pIShell, TRUE);
but if that is what you want from now on then I will mod my base class
code to do it as you have specified above.

jmiller2 wrote:Couple of questions:
1. re: "if(!wParam) // only exit on clamshell close"
How would it be possible to get the clamshell Open without
a previous close? IOW what is the point of testing wParam?
2. re: "This is a bad requirement for the reason I mentioned above, but it probably won't be changing any time in the near future"
So if Qualcomm recognizes that something is a bad requirement they
cannot specify that NSTL changes it??!!
I did,
ISHELL_CloseApplet(pMe->a.m_pIShell, FALSE);
and the app passed. I cannot fathom why we would need to call
ISHELL_CloseApplet(pMe->a.m_pIShell, TRUE);
but if that is what you want from now on then I will mod my base class
code to do it as you have specified above.
1. If the application is started while the clamshell is closed, you wouldn't want it to be terminated when the clamshell is opened.
2. Going over the requirements for section 3.6 in the testing document from the DX, it looks like the requirements are that the application exit to App Manager rather than the native idle screen. If this is the case, using FALSE would be acceptable.

jmiller2 wrote:Couple of questions:
1. re: "if(!wParam) // only exit on clamshell close"
How would it be possible to get the clamshell Open without
a previous close? IOW what is the point of testing wParam?
2. re: "This is a bad requirement for the reason I mentioned above, but it probably won't be changing any time in the near future"
So if Qualcomm recognizes that something is a bad requirement they
cannot specify that NSTL changes it??!!
I did,
ISHELL_CloseApplet(pMe->a.m_pIShell, FALSE);
and the app passed. I cannot fathom why we would need to call
ISHELL_CloseApplet(pMe->a.m_pIShell, TRUE);
but if that is what you want from now on then I will mod my base class
code to do it as you have specified above.
1. If the application is started while the clamshell is closed, you wouldn't want it to be terminated when the clamshell is opened.
2. Going over the requirements for section 3.6 in the testing document from the DX, it looks like the requirements are that the application exit to App Manager rather than the native idle screen. If this is the case, using FALSE would be acceptable.

mohlendo wrote:Yes, this is why the call requires PL_SYSTEM in newer versions of BREW. The side effect would be that other active applications are terminated.
I tried calling ISHELL_CloseApplet(pme->a.m_pIShell, TRUE) in BREW 3.0 app, but it doesn't exit the app.
where can the PL_SYSTEM be set?
Thanks,
Jean

mohlendo wrote:Yes, this is why the call requires PL_SYSTEM in newer versions of BREW. The side effect would be that other active applications are terminated.
I tried calling ISHELL_CloseApplet(pme->a.m_pIShell, TRUE) in BREW 3.0 app, but it doesn't exit the app.
where can the PL_SYSTEM be set?
Thanks,
Jean

What is the latest on this ridiculous test? Do we use TRUE or FALSE? Where do we set PL_SYSTEM? Is it acceptable to just document the behavior? It seems like in the majority of cases, FALSE is the better choice.
Obviously except for 3.x, but seriously, why the heck would an application FAIL if it goes to the AppManager versus the OEM screen? I think we should all be worried about memory leaks and phone bricking a little more than this stupid requirement.
Qualcomm and NSTL, could we PLEASE have a consistent answer to these questions?
Thanks,

What is the latest on this ridiculous test? Do we use TRUE or FALSE? Where do we set PL_SYSTEM? Is it acceptable to just document the behavior? It seems like in the majority of cases, FALSE is the better choice.
Obviously except for 3.x, but seriously, why the heck would an application FAIL if it goes to the AppManager versus the OEM screen? I think we should all be worried about memory leaks and phone bricking a little more than this stupid requirement.
Qualcomm and NSTL, could we PLEASE have a consistent answer to these questions?
Thanks,

Exiting to AppManager on EVT_FLIP is an acceptable result. You would want to use FALSE in ISHELL_CloseApplet() for any of the currently commercial 3.x devices (it's also acceptable for 2.x devices that don't allow you to pass TRUE). Future clamshell devices are supposed to close all applications when the user returns FALSE to EVT_FLIP, but this is a new recommendation and may not appear for some time.

Exiting to AppManager on EVT_FLIP is an acceptable result. You would want to use FALSE in ISHELL_CloseApplet() for any of the currently commercial 3.x devices (it's also acceptable for 2.x devices that don't allow you to pass TRUE). Future clamshell devices are supposed to close all applications when the user returns FALSE to EVT_FLIP, but this is a new recommendation and may not appear for some time.

mohlendo wrote:Exiting to AppManager on EVT_FLIP is an acceptable result. You would want to use FALSE in ISHELL_CloseApplet() for any of the currently commercial 3.x devices (it's also acceptable for 2.x devices that don't allow you to pass TRUE). Future clamshell devices are supposed to close all applications when the user returns FALSE to EVT_FLIP, but this is a new recommendation and may not appear for some time.
That's about as clear as mud.
"it's also acceptable for 2.x devices that don't allow you to pass TRUE"
How does one Test for/know this?
Think about it in the context of trying to write code that will
work on every device without having to have seperate builds.
IOW I just want to modify my base class when the carriers
change the requirements, not waste tons of time testing on
every handset for a feature that no one is using.
Why should it ever be a requirement for me to close other applications?
They should get their own message and close themselves.
Are there ever going to be any requirements on the OEM's to adhere to
some standards?

mohlendo wrote:Exiting to AppManager on EVT_FLIP is an acceptable result. You would want to use FALSE in ISHELL_CloseApplet() for any of the currently commercial 3.x devices (it's also acceptable for 2.x devices that don't allow you to pass TRUE). Future clamshell devices are supposed to close all applications when the user returns FALSE to EVT_FLIP, but this is a new recommendation and may not appear for some time.
That's about as clear as mud.
"it's also acceptable for 2.x devices that don't allow you to pass TRUE"
How does one Test for/know this?
Think about it in the context of trying to write code that will
work on every device without having to have seperate builds.
IOW I just want to modify my base class when the carriers
change the requirements, not waste tons of time testing on
every handset for a feature that no one is using.
Why should it ever be a requirement for me to close other applications?
They should get their own message and close themselves.
Are there ever going to be any requirements on the OEM's to adhere to
some standards?

Ok, to clarify:
You should never be failed for passing in FALSE to ISHELL_CloseApplet().
Clear enough? :cool:

Ok, to clarify:
You should never be failed for passing in FALSE to ISHELL_CloseApplet().
Clear enough? :cool: