I have a question that is purely out of curiosity. I'm not a developer, nor do I have any desire to become one... at this time.
In the process of answering questions for my father about his new Android phone, I came across the Android Developers website. Being the infinity curious person that I am, I started to browse through it and came across something that I was particularly curious about, the "Forward-Locked Application" market filter. It states that an application in the market can be set to not be visible to developer devices and unreleased devices. What I'm curious about is why would a developer not want their app to not be visible to said devices? Wouldn't it be to their advantage to allow their app to be visible, installed, and possibly tested if the owner of the developer phone or new unreleased phone so chose to do, after all, this is potentially new hardware that the app developer may not have support for in their app. Now not being a developer myself, I'm sure there are valid reasons for the filter and I am just curious as to what they may be.
Because you haven't tested your app on a new OS build, and want ensure compatibility before offering it for sale. Other reason is that the new OS build either obsoletes, duplicates, or just plain breaks your app. An example would be the updates to the calendar API's in Android 2.2. Every calendar widget in the market that tied into the built-in calendar app ceased to function because the way it interacted with outside apps had changed.
So the lock is not in reference to developer or unreleased hardware, it pertains to developer or unreleased software or OS?
They would check build/version number in the build.prop or whatever they use... It's just like how FroYo builds couldn't see protected apps while it was in pre-release.
garfnodie said:
So the lock is not in reference to developer or unreleased hardware, it pertains to developer or unreleased software or OS?
Click to expand...
Click to collapse
yes this is correct. The developer phones have different software that allow native root access and this would be defined in the build.prop . That would also allow people to rip applications and pirate them.
That switch is mainly a quality assurance/anti-piracy measure.
ATnTdude said:
Because you haven't tested your app on a new OS build, and want ensure compatibility before offering it for sale. Other reason is that the new OS build either obsoletes, duplicates, or just plain breaks your app. An example would be the updates to the calendar API's in Android 2.2. Every calendar widget in the market that tied into the built-in calendar app ceased to function because the way it interacted with outside apps had changed.
Click to expand...
Click to collapse
Actually, those apps that broke, broke because they were using private APIs. As explained, if you stick to public APIs your app should not break when updating OS iterations because ALL APIs are frozen as soon as a release is cut.
Here's another question then, are app's allowed to do automatic bug reporting back to a developer with out the user consent, or even with the users consent. It seems to me that say Google is testing Android 3.0, and one of their in house testers decides to install your app, but your app does not support 3.0 for whatever reason, if there is automatic bug reporting, you could be made aware of a potential incompatibility with a new API and have time to fix it long before the new OS is ever released. This all could never happen though if you have the market filter set.
garfnodie said:
Here's another question then, are app's allowed to do automatic bug reporting back to a developer with out the user consent, or even with the users consent. It seems to me that say Google is testing Android 3.0, and one of their in house testers decides to install your app, but your app does not support 3.0 for whatever reason, if there is automatic bug reporting, you could be made aware of a potential incompatibility with a new API and have time to fix it long before the new OS is ever released. This all could never happen though if you have the market filter set.
Click to expand...
Click to collapse
bug reporting is going to be a new feature of 3.0. I dont think many if any apps have their own built in bug reporting. Also it really is on the developers side if their app doesnt work with new OS revisions. They should program their apps in such a way that they wont have to make drastic changes for updates. Google also give plenty of time for developers to make fixes before the first iterations of the new update goes out (almost 1 month in the case of froyo)
however some developers just dont care (e.g Co-Pilot)
I'd like to be able to track the Version number of my application, and the Device Model name for people connecting to my application; What is the best way of achieving this?
I'm assuming that I might be able to do something like:
Device Model Name
tracker.trackPageView("/testApplicationHomeScreen/"+Build.MODEL);
Version Number
tracker.trackPageView("/testApplicationHomeScreen/"+packageInfo.versionName);
Will this work, and is this the best way of achieving this, or should I be using Events?
Cheers,
James.
I've been playing around with this since posting the question. I've found that Events are the best way of achieving this.
ie create categories for "Version" and "Model", then track each detail using events. This then gives you the granular results I required to be able to see which versions of my app were being used, and which handset models were in use as well.
I have a user of my app who is having a problem running it. My code launches another activity in the same app, and he is saying it is stopping before it should & returning to the previous activity, and he doesn't see any Force Close warnings.
I have run my code in the emulator & on my phone, I can't reproduce the error. We both run Android 2.2 on our phones, his is an HTC EVO & mine is a HTC Wildfire, as far as I can tell his specs are better than mine so shouldn't cause an issue - I deliberately chose a low spec for for my dev work so the code ought to run on anything.
As a bit of an Andoid dev noob (but been coding for years), is there any easy way I can make a special build of the app to send to him that would log any errors that happen ? I'd like to get a stack dump as well if possible, as I'm not sure exactly what routine in the activity its crashing out in. The activity that crashes is Gallery with 9 images in it, he can't flick through them or select one. I'm stumped as to whats causing it, any assistance would be gratefully received.
Thanks.
Why not point to your app and let others here try it on their phones? It could simply be other apps installed on his phone interfering with your app.
Long time programmer here too and when I get to where you're at (and I"m sure you've put some hours into this LOL), I go back to STEP 1.
I comment-out any and all code but the bare minimum; break it down to the Intent, startActivity and maybe a Toast message in the second activity. Even parse down your XML files to bare minimum.
See if that works. Then, ADD BACK ONE LINE OF CODE AT A TIME Run program and make sure it works. Yeah, it's painful, but in my 20 years of coding, I've learned to put my pride aside and to not "pretend" all the code I've written is correct.
Sometimes on bigger projects, I"ll change or add a couple of lines of code, run a back up and test. Rinse and repeat LOL. That way, I know I"m only a couple of lines of code from what "used" to work.
Good Luck!
Thanks both of you.
old_dude - Its a paid app. Only £0.99 but I don't think people would pay to help me. There is a free version of the same app (with less functionality) that this guy can get to work. If your really interested the 2 versions are -
Plink Log - Free Version
Plink Log Pro - Paid version
Rootstonian - agreed thats the approach I'd normally take if I was having problems on my dev phone or the emulator. The problem is that its OK on my HTC Wildfire/Android2.2 but on this guys HTC EVO/Android2.2 its having problems. I dont really want to keep sending him .apks with 1 or 2 lines extra enabled just to see if that fixes his specific issue. I was hoping there was something I could code to catch whatever crashes the activity & log it somewhere for me to analyse. When I do PC dev work, I have a global exception handler that catches anything I dont explicitly handle, and dumps the full call stack into a Log File I can read later.
I think I'll just have to take the existing app & put loads of debug code into it to save messages into a log file & see what bits of code are being called & what isn't & then get him to email me the results.
Thanks for the ideas guys, its always useful to get input from another perspective.
Dave
Hmmmm, just discovered setDefaultUncaughtExceptionHandler - might be able to use that with printStackTrace. Sounds interesting.
I've seen a couple posts regarding getting Google Wallet to work (and hopefully I'm not being redundant with this post). I've had Google Wallet working on my own 2.3.5 source ROM for quite some time now and I figured I'd share what got it working for me. As a matter of disclosure, I do have the 4G, but I haven't seen anything in the code that would give reason for why this wouldn't work.
While I'm able to build a ROM, I for some reason, don't know how to put together a flashable update. Maybe somebody with a little more know-how can piece this together and try it out, or at least tell me I'm wrong.
Files needed from the GWK74 ROM:
system/etc/permissions/com.google.android.nfc_extras.xml
(I just added the permission entry to the existing com.android.nfc_extras.xml file instead to keep the clutter down).
system/framework/com.android.nfc_extras.jar
The version in the GWK74 ROM contains code that has yet to be released, since korg is down and all. The extra file has something to do with NFC emulation, but I've only glanced at it, so I really couldn't tell you what it does.
system/app/Wallet.apk
Obviously.
Here's the catch: The Wallet app requires permissions from Nfc.apk (NFCEE_ADMIN). By default, the Nfc.apk is signed with the "platform" key, but as long as these two files are signed with the same key, it will grant it the proper permissions to Wallet.apk no matter what key that may happen to be. Considering that Nfc.apk also requests other permissions from "platform" as well, certificate consistency would be advisable.
Hope this works out or at the very least, gets the ball rolling.
Hopefully, someone can make like a flashable zip for CM7 or at least let us know which files need to be copied to our GSM phones so we can extract those files and copy it to system
do you mind zipping up the files used and posting them here?
They're basically the stock files from GWK74 with Wallet.apk and Nfc.apk signed with the same key. My only concern is that since I've used a private key on my own ROM for a while now, I don't remember/know how many or which non-stock ROMs are signed with anything other than the testkeys or which key would be the best for (most) everyone. If the testkeys work universally, I could do that, but I'd hate for someone with differing platform keys getting upset that it's still doing the same FC as before.
For those familiar with using the Android Kitchen, it can do the signing and packaging with testkeys if you're willing to reflash. Might be an easier step for some to take if the command line method seems overwhelming.
As far as Google Wallet working on a GSM Nexus S. I believe there is more protection than it appears. I firmly believe Google has not only modified the NFC drivers and added NFC security to both the drivers and the Firmware. But I also think they added security to the rils and network checks.
How did I get to these conclusions? Well I actually ported the whole NS4G rom over to the GSM. The only things I really had to change were ril libs and the build.prop. Everything else is pretty similar between the two phones. NFC worked and I was able to start up Google Wallet, however, when attempting to add a card to Google Wallet, it kept loading for like 10 minutes until it gave an error. No real description of the error and logcats revealing nothing. Taking out my sim card, I was greeted with a message in Google Wallet that I should check my sim card and insert it if its not inserted. Why would Google Wallet even have anything to do with carriers even connected to wifi? There must be some other things added.
Then I went ahead and decided to revert to a backup of my CM7. I noticed NFC no longer would turn on, it kept giving me an error. Looking at a logcat it looked like it was trying to download and install firmware but failed. Other NS4G users have experienced this same error. Logcats show that it is downloading firmware but failing to be able to install it. My theory: Google added extra security to the firmware located directly onto the NFC chip itself. So now no ROMs (including the new 2.3.6) give me working NFC except for that 2.3.7 rom. I'm still working on trying to fix.
Now I am happy you posted this thread, because maybe if I backport these additions to a GSM rom I might be able to fix NFC. I'm not sure as of yet. I am going to attempt Odin next, but I can already guarantee Formatting System, Boot, Cache, Data did not resolve the issue.
They definitely added something to the firmware. After flashing GWK74 nfc no longer works on 2.3.5. If I flash back to GWK74 it works no problem.
Sent from my Nexus S 4G using xda premium
U could test that driver theory with a chip that hasnt gotten the 2.3.7 update.
apreichner said:
As far as Google Wallet working on a GSM Nexus S. I believe there is more protection than it appears. I firmly believe Google has not only modified the NFC drivers and added NFC security to both the drivers and the Firmware. But I also think they added security to the rils and network checks.
How did I get to these conclusions? Well I actually ported the whole NS4G rom over to the GSM. The only things I really had to change were ril libs and the build.prop. Everything else is pretty similar between the two phones. NFC worked and I was able to start up Google Wallet, however, when attempting to add a card to Google Wallet, it kept loading for like 10 minutes until it gave an error. No real description of the error and logcats revealing nothing. Taking out my sim card, I was greeted with a message in Google Wallet that I should check my sim card and insert it if its not inserted. Why would Google Wallet even have anything to do with carriers even connected to wifi? There must be some other things added.
Then I went ahead and decided to revert to a backup of my CM7. I noticed NFC no longer would turn on, it kept giving me an error. Looking at a logcat it looked like it was trying to download and install firmware but failed. Other NS4G users have experienced this same error. Logcats show that it is downloading firmware but failing to be able to install it. My theory: Google added extra security to the firmware located directly onto the NFC chip itself. So now no ROMs (including the new 2.3.6) give me working NFC except for that 2.3.7 rom. I'm still working on trying to fix.
Now I am happy you posted this thread, because maybe if I backport these additions to a GSM rom I might be able to fix NFC. I'm not sure as of yet. I am going to attempt Odin next, but I can already guarantee Formatting System, Boot, Cache, Data did not resolve the issue.
Click to expand...
Click to collapse
Thanks for chiming in. Appreciate the info
Hmm, that's odd because aside from those three files and the vendor binaries, everything else on my ROM is from the 2.3.5 source files (since I don't have a choice for source files, really). The first thing I tried when Wallet was giving me fits was to poke around the APKs to see if they were holding any additional files, but I didn't locate any in Wallet and the NFC app file is too small to hold any additional files (and doesn't, since I checked anyway). The 2.3.7 nfc_extras JAR file only contains three java files (compared to the two from 2.3.5) so I don't suspect anything warranting investigation.
It's hard to imagine Google going through so much trouble to block their own product on their own phone. Unfortunately, I don't have access to a non-Sprint Nexus S, so I cannot account for the SIM message you experienced, but the hardware vendor for the NFC component appears to be the same (NXP) for both phones and it just doesn't make sense for them to use two different components for the same model of nearly identical phones. I'll try using the libpn544_fw.so binary from the standard crespo and see what kind of (ill) effects I experience.
I did notice during my trial-and-error period that the error messages and the manner in which they would show up seemed to vary slightly. Adding the JAR file alleviated the persistent com.google.android.apps.walletnfcrel FC during startup and use. After that, the signing took care of the persistent 'insufficient system privileges' (or something to that effect) on startup.
I'd be interested in what is in your log readout. Personally, logcat gets visually overwhelming to me, so I just use ddms to filter out the other processes and error messages from obfuscating what I'm looking for. The thing that Wallet is trying to access is NFC permissions, which Nfc.apk appears to have sole (or at least primary) responsibility for. All of the protests coming from Wallet that I observed were related to its inability to be granted permissions from Nfc for NFCEE_ADMIN, which is specified in its AndroidManifest file as being under protectionLevel="signature", of which it is assigned to "platform" by default. That would explain why people with the stock ROM can get it to work, since it still retains the Google signature keys structure. I suspect most of the alternative ROMs are running some varying key structure, but that is just speculation on my part. I suppose modifying the AndroidManifest file to explicitly give permission to Wallet would also address that, but at the time, I considered that unnecessarily tedious.
I'm still betting on certificate-connected privileges being the primary culprit, but I'll give the NFC binary file a run and see what happens.
Update:
Ran with the libpn544_fw.so from crespo and Wallet initially FCed. I pulled the file through ADB first to make sure it was the one installed and it was, but after the FC, I pulled the file again and it was the regular one for crespo4g. So, unless I misread it or made a mistake somewhere, something is replacing the file. I pushed the original file back, ran it, and pulled it again and it seemed to stick, but I suspect it's running from cache. So basically, it appears that the binary from crespo is insufficient, as I got numerous errors in ddms as a result. I don't know if it has the same effect both ways though. Has anybody tried the crespo4g NXP binary yet with any luck?
Also, I do apologize for some misinformation earlier. The 2.3.7 NfcGoogle.apk does contain a libnfc_jni.so file, but it's already in system/lib, so I don't know if that has to do with anything relevant.
Need some help i get this error message when i push the files to newest Cm7 nightly based on 2.3.7. Any ideas?
XK72 said:
It's hard to imagine Google going through so much trouble to block their own product on their own phone.
Click to expand...
Click to collapse
Well keep in mind it's not just Google that's involved, but MasterCard, Citi, MoneyNet or whatever that service is that processes the transactions... they may have mandated that some extra security measures be taken to keep the initial rollout limited to a relatively small specific group.
david279 said:
Need some help i get this error message when i push the files to newest Cm7 nightly based on 2.3.7. Any ideas?
Click to expand...
Click to collapse
I encountered the same issue a while back. It's related to the signature keys on Wallet, which is signed with Google's key out of the box. If the rest of your build is signed with testkeys (which appears to be the case), you can resolve that by signing Wallet.apk with testkeys as well.
tobiasly said:
Well keep in mind it's not just Google that's involved, but MasterCard, Citi, MoneyNet or whatever that service is that processes the transactions... they may have mandated that some extra security measures be taken to keep the initial rollout limited to a relatively small specific group.
Click to expand...
Click to collapse
While Google Wallet is a proprietary application, and as such, Google or the forces that be could possibly be responsible for what's occurring and I wouldn't be able to discern whether or not that is true, I personally don't believe that is the reason behind what is happening.
(This is just as I understand it). There certainly are security measures in place for NFC, which the Android system is responsible for handling. The Wallet app is essentially an interface that is PIN secured on the user end and requests relevant permission from Nfc.apk that manages interaction with the NFC-related subset on its behalf. If anything, the credit card companies are concerned with unauthorized transmissions that could result in financial liability on their end. The fact that Wallet requires signature-protected permission authorization from Nfc to access the NFC element shows that Android is not leaving security duties up to the Wallet app alone.
I think the hindrances in getting this to work for everyone is that the people who could develop a fix probably don't have access to the Nexus S hardware variants. I started with the same or similar issues that people faced when trying to incorporate Wallet into their build and eventually got it to work on a 2.3.5 sourced build was the steps above, but I also don't own a standard Nexus S for me to test with, so I couldn't proclaim that it was a definitive fix. I was hoping, at the very least, that it might be contributive towards finding a fix for everyone.
XK72 said:
I encountered the same issue a while back. It's related to the signature keys on Wallet, which is signed with Google's key out of the box. If the rest of your build is signed with testkeys (which appears to be the case), you can resolve that by signing Wallet.apk with testkeys as well.
Click to expand...
Click to collapse
How do I sign apks? Can you send me a wallet apk signed with test keys?
Sent from my Nexus S 4G using xda premium
---------- Post added at 06:03 PM ---------- Previous post was at 05:39 PM ----------
Ok i found a app in the market for signing apks, zips, etc. but im getting the same error.
XK72 said:
While Google Wallet is a proprietary application, and as such, Google or the forces that be could possibly be responsible for what's occurring and I wouldn't be able to discern whether or not that is true, I personally don't believe that is the reason behind what is happening.
(This is just as I understand it). There certainly are security measures in place for NFC, which the Android system is responsible for handling. The Wallet app is essentially an interface that is PIN secured on the user end and requests relevant permission from Nfc.apk that manages interaction with the NFC-related subset on its behalf. If anything, the credit card companies are concerned with unauthorized transmissions that could result in financial liability on their end. The fact that Wallet requires signature-protected permission authorization from Nfc to access the NFC element shows that Android is not leaving security duties up to the Wallet app alone.
I think the hindrances in getting this to work for everyone is that the people who could develop a fix probably don't have access to the Nexus S hardware variants. I started with the same or similar issues that people faced when trying to incorporate Wallet into their build and eventually got it to work on a 2.3.5 sourced build was the steps above, but I also don't own a standard Nexus S for me to test with, so I couldn't proclaim that it was a definitive fix. I was hoping, at the very least, that it might be contributive towards finding a fix for everyone.
Click to expand...
Click to collapse
I will attempt to port it over. Good news is there's some 2.3.7 source available now to build with. I don't have much hope though because a full port didn't even work on a GSM device. Although newer libs might help.
Sent from my Nexus S using xda premium
apreichner said:
I will attempt to port it over. Good news is there's some 2.3.7 source available now to build with. I don't have much hope though because a full port didn't even work on a GSM device. Although newer libs might help.
Sent from my Nexus S using xda premium
Click to expand...
Click to collapse
Do you know where they're hosting the 2.3.7 source? I just realized that they released the 2.3.7 binaries for both crespo and crespo4g, so between those two, there really shouldn't be anything else getting in the way of making this work.
Here: http://forum.xda-developers.com/showthread.php?t=1284517
People are reporting that Wallet works just fine on I902x phones and stock rooted 2.3.6. I'm only one there unable to add prepaid card. Guess it's because my IMEI is generic, and i'm pretty sure that google is using IMEIs for authentication and similar processes...
One factor may be branch of code. In build numbers, the letters have meanings. First letter is Android version (G for Gingerbread). Second letter is branch. Usually this is R for Release. The build for NS4G is W. I don't know what this W branch is. Maybe special "Wallet" branch.
http://source.android.com/source/build-numbers.html
Sent from my Nexus S using XDA App
can anyone make a patch for all variants of hd2 roms from gb up i used the bluebox app to check if my phone was vunerable for this bug 13678484 (fake id) and my daily driver barebone cm7 v2b was, and id say all roms developed for hd2 are vunerable have searched the net for how to patch this vunerability but cant find the info abywhere this is something i think all xda devs for this device will have to sort out as we cannot get help from carriers on this as this is what advice is given "contact your carrier or phone vendor for patch. if anyone has advice on how to sort this out would be very thankful i think xda should run a piece about this vunerability and what steps are being taken by all devs on xda to patch this vunerabilitu for older handsets likemy hd2.
Bluebox Security revealed a significant security flaw that affects all Android devices since version 2.1. Our hyperbolic title mocks the fact that he had little to ignite the Internet powders. If the fault is real, it should take a step back and put the case in context instead of screaming panic for nothing.
A serious flaw that affects a large number of terminals
Very schematically, the fault Fake ID allows malware to authenticate using the signature of a known application to hide its true origin. The firm provides an example of a virus masquerading as an Adobe Systems and Google software which would be able to become a Trojan horse or steal data used by Google Wallet acquiring the necessary permissions without using the user.
The flaw is serious. However, Google has already been made aware, he has already released a patch he sent to his partners, he corrected the flaw in Android 4.4 KitKat, he scanned the Google Play and can say that no application in its store uses this vulnerability. Finally, Verify Apps, which monitors the behavior of applications on an Android device, is also fixed and can detect an application attempting to exploit Fake ID.
A patch already in place and a flaw in a very limited scope that still show that Google still has work to do in terms of security
In short, it is true that it is possible to be a victim of this fault, but it requires a terminal that has not been updated, download an application containing malware does not come from Google and Play Verify Apps have disabled or have an Android version of which is free. Suffice to say that the cases in question are very limited.
This flaw shows that Google still has work to do in terms of its security strategy. Last month, we décriions lax features the Play Store. Today, we are dealing with a flaw of a limited scope, but was discovered by analyzing the shortcomings of the source code of the operating system.
This flaw shows that Google still has work to do in terms of its security strategy. Last month, we décriions lax features the Play Store. Today, we are dealing with a flaw of a limited scope, but was discovered by analyzing the shortcomings of the source code of the operating system.[/QUOTE]
while the info you have given is fine and i thank you for it, but there are other app stores people use beside google play store and reading up on this bug it is still possible their phones could become compromised downloading apps from them?
A Big Big Thank You
Just an update: opssemnik backported the fake id xposed module and it works perfectly with gb roms a big big thank you to him. he also supplied a link in the comments on http://www.xda-developers.com/android/fight-fake-id-vulnerability-xposed/ So once again a big thank you to opssemnik