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

Developer

Forums

Forums:

Is there any API function that Which phone is LG, Motoroal,Samsung .....?

Yes, You can. Each & every device have unique platform id. Using that you can identify which device it is. But i dont think you can identify the name(LG,Samsung....) of the device.

Yes, You can. Each & every device have unique platform id. Using that you can identify which device it is. But i dont think you can identify the name(LG,Samsung....) of the device.

Actually, if this is for BREW 1.0, I believe there is no way to do this. You need to write a handler to "best guess" your device. I think platform id support starts at 2.0.

Actually, if this is for BREW 1.0, I believe there is no way to do this. You need to write a handler to "best guess" your device. I think platform id support starts at 2.0.

It has been part of Brew 1.1 becasue I've been using it for the longest time. The function is ISHELL_GetDeviceInfo(). Check the 1.0 SDK documentation to see if it's included there as well, but you may also ask yourself if it is really necessary to write you application in Brew 1.0, which is entirely outdated.

It has been part of Brew 1.1 becasue I've been using it for the longest time. The function is ISHELL_GetDeviceInfo(). Check the 1.0 SDK documentation to see if it's included there as well, but you may also ask yourself if it is really necessary to write you application in Brew 1.0, which is entirely outdated.

Yes, i am sure it is also in BREW SDK 1.0
Just now i gone through the document. BREW 1.0 supports ISHELL_GetdeviceInfo(). BREW 2.0 supports ISHELL_GetdeviceinfoEx().

Yes, i am sure it is also in BREW SDK 1.0
Just now i gone through the document. BREW 1.0 supports ISHELL_GetdeviceInfo(). BREW 2.0 supports ISHELL_GetdeviceinfoEx().

There you go. That solves your problem, toltoly

There you go. That solves your problem, toltoly

Hmm, that is odd. I actually had to write an app for 1.0 (only because it had to be one package across multiple platforms, some of which were 1.0. During that time, I looked at ISHELL_GetDeviceInfo and there was no entry in AEEDeviceInfo for the platform within the v11 Brew documentation that was installed with that version of the API.
BUT ... I did look at the include file AEEShell.h , and sure enough there is an entry of dwplatformID! It is the last element in the struct. So if it is really supported ... then that is cool.
Sonnofa B, since for that app I wrote, I added a device "guesser" since I saw another thread in this forum that said it wasn't supported properly. Ugh! Oh well, chalk one up for building character.
BTW, you can use ISHELL_GetDeviceInfo in BREW 2.0 for device recognition. That totally works.

Hmm, that is odd. I actually had to write an app for 1.0 (only because it had to be one package across multiple platforms, some of which were 1.0. During that time, I looked at ISHELL_GetDeviceInfo and there was no entry in AEEDeviceInfo for the platform within the v11 Brew documentation that was installed with that version of the API.
BUT ... I did look at the include file AEEShell.h , and sure enough there is an entry of dwplatformID! It is the last element in the struct. So if it is really supported ... then that is cool.
Sonnofa B, since for that app I wrote, I added a device "guesser" since I saw another thread in this forum that said it wasn't supported properly. Ugh! Oh well, chalk one up for building character.
BTW, you can use ISHELL_GetDeviceInfo in BREW 2.0 for device recognition. That totally works.

I am using a mix between platformiD read-out and device guesser. If the device reports no deviceID or if the deviceID is unknown to my application it checks the display resolutions of all known handsets for the closest one and assimilates that. That approach works particularly well when you have handsets like the vx6000 which suddenly have 3 or 4 different device ids.
Still, I wish Qualcomm would have properly separarated device id and carrier/hardware/firmware revisisons instead of mashing it all together.

I am using a mix between platformiD read-out and device guesser. If the device reports no deviceID or if the deviceID is unknown to my application it checks the display resolutions of all known handsets for the closest one and assimilates that. That approach works particularly well when you have handsets like the vx6000 which suddenly have 3 or 4 different device ids.
Still, I wish Qualcomm would have properly separarated device id and carrier/hardware/firmware revisisons instead of mashing it all together.

Dragon wrote:... when you have handsets like the vx6000 which suddenly have 3 or 4 different device ids.Oh no, really? ... the preceding should be read with extreme sadness (and a tinge of disgust).
Do you know if this is documented somewhere? Are the id's known, or are they random?
Thanks,
Paul

Dragon wrote:... when you have handsets like the vx6000 which suddenly have 3 or 4 different device ids.Oh no, really? ... the preceding should be read with extreme sadness (and a tinge of disgust).
Do you know if this is documented somewhere? Are the id's known, or are they random?
Thanks,
Paul

It is not really documented, no. You can go to NSTLs website and when you select individual handsets it shows which platformIDs are covered by this handset, but even that is cinmplete. Only once you app is fully submitted you can see on the Extranet exactly which platformIDs your app is tested and grandfathered on.
I agree, it is a pity that Qualcomm didn't even get something as trivial as a working device identifier implemented properly, which once again just underscores my point that BREW is being conceived and implemented by academics who have yet to write a real-life application. Early versions of Brew did not have platformIDs at all, which basically says it all...
Still with a mix of platformID and a guesser, it has been working fine for me so far though it's hardly elegant or an industrial strength implementation.

It is not really documented, no. You can go to NSTLs website and when you select individual handsets it shows which platformIDs are covered by this handset, but even that is cinmplete. Only once you app is fully submitted you can see on the Extranet exactly which platformIDs your app is tested and grandfathered on.
I agree, it is a pity that Qualcomm didn't even get something as trivial as a working device identifier implemented properly, which once again just underscores my point that BREW is being conceived and implemented by academics who have yet to write a real-life application. Early versions of Brew did not have platformIDs at all, which basically says it all...
Still with a mix of platformID and a guesser, it has been working fine for me so far though it's hardly elegant or an industrial strength implementation.

Dragon wrote:... which once again just underscores my point that BREW is being conceived and implemented by academics who have yet to write a real-life application.I think you're giving academics a bad name. I know plenty of academics that could do a much better job (examples upon request). Actually, I believe one of QC's main problems with BREW is that they are an IP shop and want to keep everything as close to the vest as possible ... of course, the Jacobs are all rich and I'm not, so what do I know.
BTW, thanks for the info.
Paul

Dragon wrote:... which once again just underscores my point that BREW is being conceived and implemented by academics who have yet to write a real-life application.I think you're giving academics a bad name. I know plenty of academics that could do a much better job (examples upon request). Actually, I believe one of QC's main problems with BREW is that they are an IP shop and want to keep everything as close to the vest as possible ... of course, the Jacobs are all rich and I'm not, so what do I know.
BTW, thanks for the info.
Paul

That's splitting hairs and I'm not going to get into that.
As for the IP shop, that's where Qualcomm's flabberghasting paranoia comes from and some of the decisisons/behavior that just make you scratch your head. The firmware bugs, the poor attitude towards developers and the lack of quality or foresight in their software and tools is a different story entirely and has nothing to do with that.

That's splitting hairs and I'm not going to get into that.
As for the IP shop, that's where Qualcomm's flabberghasting paranoia comes from and some of the decisisons/behavior that just make you scratch your head. The firmware bugs, the poor attitude towards developers and the lack of quality or foresight in their software and tools is a different story entirely and has nothing to do with that.

thank you.

thank you.