I've released an app about a month ago now, and it works as it should on my Desire and presumably on a lot of other phones. However it is also receiving it's fair share of 1 star ratings with comments that say that the sound simply doesn't work. Given that this is an app to play sounds and alarms that's a pretty major problem.
Thankfully one user emailed me to say it didn't work for her, so I at least know one model of phone it's not working on. However I have ZERO idea how you would even begin to work out why code isn't working on a particular phone. If the code is written as per the android docs, and it works in the emulator and on my own phone, I can't begin to work out where to start fixing this.
Any ideas?
If you are contacted by a reasonably advanced user, they could either install a logcat app such as aLogcat or access logcat output over USB if they have the SDK installed, and mail you the output of the phone logs after running your app. It might have some hint as to what is failing.
Related
a colleague of mine is working on a legacy ReactNative app. There is quite a lot of code both in JavaScript and Java land, the latter being related to HERE Maps SDK.
Two of our clients experience multiple crashes every day and we cannot figure out why as we have no error reports.
Bugsnag was installed early last year (circa jan 2020) and we have nothing on there to help us. Nothing to be found in Google Console either. App just stops.
To help us debug we've added a logging system which sends debug info to our backend via dedicated API calls.
It roughly consists of logging "start of function A", "end of function A" etc so we know what the app is doing. We don't always enable it as it tends to make the app even more unstable.
In parallel to that we managed to get an idea of when the app crashes via login events that are sent by Firebase Auth when user re-launches the app.
Looking at our logs around the time of crash doesn't help us as 1) they look the same as when it all works and 2) we haven't covered all method calls as there are way too many (in JS and Java).
Our users run the app on a Samsung Galaxy Active Tab 2 mounted in the cabin of a tractor. Some use a Galaxy Active Tab 3 and also have the issue.
We have run through various theories :
Could it be too hot in the cabin so Android shuts down? No, tablet is always on according to clients.
Could it be related to a change in voltage? When WE try to plug and unplug everything continues to work fine.
Could it be Android that decides the app is consuming too much battery or CPU (GPS is needed for our app) so it shuts it down? We've let our app in the foreground for hours with no problem.
We logged in with customers' credentials (they are aware) and could not replicate the issue.
Customers interest in helping us find the issue is slowly fading away so we can't keep on asking them to install a patched version every week.
First there was just one client but now we have at least 3 more users complaining about mysterious crashes.
We're a bit stomped as to what to do.
Has anyone any idea of an ultimate catch all library? Or a syslog on the tablet where we could get more info?
Thanks in advance for your help!
After much testing my colleagues managed to easily reproduce the error and found the root cause: poor memory management in one method in Java land.
Said method was responsible for changing markers orientation on the map but it duplicated markers when their orientation changed. It resulted in a high memory consumption and when it reached a certain point Android would just kill all running apps.
My colleague fixed the leak and we're good! Onto the next bug now. :)
The below reasoning is based on hardware failure. If your software hasn't drastically changed (the app or the operating system), then this is a likely scenario:
The Tab 2 was released in 2012, so we're talking about a device that is up to 9 years old. If the users all use the same hardware, and the software hasn't been changed for a while, it could be some kind of hardware failure. It could be related to the vibrations of the tractor, moisture over time, or just because they used the tablet more intensively than you use yours. There could be something (semi-)loose or the memory (SSD or RAM) could start becoming faulty.
It can be a software error too of course, but it's unlikely if you haven't updated in a long time - assuming the tablets haven't been updated either.
Could you perhaps swap your tablet with one of a customer. Preferrably a customer that has the issue most often. Then observe if the issue is resolved.
This way, you'll be able figure out if it is related to the tablet (being broken) or the environment (tractor) it is being used in.
If the issue persists after a tablet swap, it's either the environment or the software, but you'd have ruled out the hardware.
If the issue is resolved, you'll know for sure it's the hardware at fault.
I'm having trouble with an app I published that sends user notifications.
The notifications are called from a background service that checks for a boolean that gets saved to SharedPreferences when the user selects to enable notifications or not.
However, I've had some users on the Galaxy S5s say that they can't turn them off (I test with nexus devs and have beta testers on m8, etc). How do I address this issue?
What is the strategy for solving problems that arise only for specific devices?
IMO, Android kinda sucks in that regard. There is absolutely no way to guarantee that if one piece of code that works on one device works on another one. Since Android is open source, manufacturers usually modify the firmware to make it kinda customized. However, they sometimes change things that will affect performance of a single function.
It is even worse! Your code might work on S4 with Android JellyBean, but not work with the same device Android Kitkat. Anyways, no - there is no way to debug without the actual device. However, you can log different events in your code and use an analytic service (like Google Analytics) and send the data to your database to study and figure out the problem. This is the method that I typically use in such cases.
If the problem is that the app crashes on some device. It is even easier. Users need to press on the "send crash data" button - so you can study the log on your developer account.
I have an android app with more than 500,000 users. I want to try to port it to WinPhone7, but I haven't any smartphone with WinPhone7. Is a real device needed to publish an app on WinPhone? Is there some developper phone?
First of all, I will say that for some scenarios, there is no real substitute for have a physical device to test against. Having said that, I would suggest that 99% of what most apps will do can be developed and test perfectly well on the emulator that comes with the developer tools.
The advantage of the emulator is that you can write and test without shelling out for the hardware and then signing up to create.msdn.com to get it (officially) unlocked, but once you are ready to deploy to the marketplace you will need to sign up anyway.
In your case, I'd say the main word in your question is "try". You don't seem confident in being able to port to the platform so the emulator route seems like the best starting point.
Your will find a Windows Phone 7 emulator in the Windows Phone SDK. You can download it for free on create.msdn.com.
There is an Android to Windows Phone API mapping tool and Windows Phone 7 Guide for Android Application Developers white paper as described on the Windows Phone Developer Blog that you should find very useful.
For getting a development device, you should reach out to Brandon Watson or your local Microsoft WP7 dev rep.
Simple answer - no, you don't. There are plenty of applications out there that were published without being tested on an actual device. Whether it's a good idea or not - that is the main question here. Depending on your application type and its behavior, you might actually need a device.
Also, another problem is the fact that the resources used by the emulator are different from the resources used by the actual device. That being said, if your application runs just fine in the emulator, it will not necessarily run the same way on a device.
You can use the WP7 emulator to test your application. But if you want to deploy it on a real phone, you will have to unlock it though the App Hub portal. That will cost you 100 dollar/year though.
As you and others have rightly pointed out, you can start porting your application using the emulator. There are differences in the emulator and real devices. In particular, to answer your question, emulator does not take pictures.
If your Android app really has half a million users, MS will happily give you a developer device (nearly) for free.
Contact #BrandonWatson or #FrankPR on Twitter.
From my experience I can tell you, that the emulator works very well. But once in a while you will stumble about a problem that you don't understand why it happens. Then you try it on the phone and it works... So... The answer is yes...not!
I am running into countless problems with the emulators of different versions. Sometimes it loads, othertimes it hangs, I've tried reinstalling the SDK and platforms etc. Even though I've a reasonably a high-end machine, when I manage to get it working performance is very slow.
Therefore, I'm thinking of buying a real phone to test out on. If I do so, can I get away with buying one second hand without bill-plans, SIM card etc? I only want it to test out on, I don't want to get stuck with bills for something I don't need to use.
Any advice is appreciated.
Thanks
I gave up the emulators a long time ago. As you are saying, it's slow.
If you want to get away cheap buy a "LG Optimus One P500", you can get it for ~150EUR. But it all depends on what version of Android you wanna develop for. No SIM or other fancy stuff is needed.
You should really check andoid x86 project http://www.android-x86.org/ You can find some instructions on the web how to get it working with ADB.
I would say you get a Droid Incredible, cheap but I think its one of the best and cheapest Droids out. But yes the emulator is horrible, I have to use my own phone to test.
Get a phone from Cricket you don't need a plan from there.
You can use any Android phone you buy for testing without having a contract. Without a contract, you won't get phone service or 3G/4G, but everything else will work just fine. You can buy one used or at full retail from a provider. Just don't activate a service plan.
I have recently published my second app on the Android Market. I've gotten a few e-mails about the app crashing on open, and all users were using the Motorola Backflip. It seems to work fine on all other devices. The app shows the background image, but crashes right after that.
Is there something different I have to do when coding for that device?
The strange thing is that it is very similar to my first app, which seems to work just fine for them. The major difference is that my second app is a paid app, and uses Android Licence Verification. My implementation should catch any license errors though, and I've tested this on my device.
Users have uninstalled and reinstalled the app without success. I'm stumped.
The other thing they're reporting is that the icon doesn't even show properly, but rather is a gear in a box, which makes me think that something goes awry very early in the installation process.
The solution was to have a user install aLogcat on their phone to send me the log.
It had to do with onCreateDialog. I was returning several dialogs, but one of them actually called .show(), which it's not supposed to do, of course. The thing is that this didn't cause an error on any phones except for the Backflip. The emulators also didn't error, or even warn me about it.
I have a motorola backflip and i can say that is not a good product....it's crashing for a lot of things....don't worry, your app is not wrong, the phone is wrong...