First off, this has never happened before on any other android device I've used (multiple devices have been tried and tested before this).
Now I have an app that I have worked on for a little over a year now, it is called AutomatedId (on the app store) and it has worked quite well for my company for quite some time.
Recently I have been given a device to add compatibility to the app (specifically for reading UHF tags) but that isn't the problem.
The problem comes whenever you open the app, the screen stops reading inputs completely, as well as buttons cease to function. I turned on developer options to see the screen inputs and as i suspected, it completely stops and does not read any of the inputs after the app is opened. Clicks don't work, buttons don't work, keyboard doesn't open, hardware buttons on the device stop working. It's a mess, does anyone know what could have caused this?
This is a S98 from here: http://www.wepoy.com/product_view_18.html
moved my comment to the answer as you said. This may be due to memory leak. Here are some references that may help you fix them: Fixing-Memory-Leaks-in-Android-Studio & use this library from square to detect memory leaks early: leakcanary
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
I'm looking for a reliable way to let the Android user show a web site on the lock screen.
This could be done in principle in 3 ways:
Showing it on the native Android lock screen, but then they should be able to remove the native clock because my site is a world clock (you can see it at intelnav.50webs.com/world_time.html if you're interested). For all I know this can't be done.
Using a 3rd party custom lock screen that allows this. Unfortunately I couldn't find a good one, and I did some searching.
Writing a custom lock screen myself.
There are some suggestions and even sample projects for doing this, even some questions here on StackOverflow. But I'm not sure how reliable they are. There is no standard way of doing it, from what I found, since lock screen widgets were removed. But the proposed ways of building custom lock screens don't seem very reliable to me, from what I could judge from the comments I could find. So, one of my questions (sorry but the problem is somewhat complex), does anybody know of a sample project for a custom lock screen that actually has an app built by it and offered on Google Play and which actually works well on a wide range of devices ?
Could anybody help me with a suggestion for a reliable way to do what I want? Along the lines above?
Looks like I'm going to answer my own question. I'm not sure how many will be interested but you can never know.
Update sep 18: Now there is a short answer that wasn't available a year ago when I first answered it. Namely, my own WebLock app:
https://play.google.com/store/apps/details?id=com.simionescu.vlad.weblock
Below is my original answer that gives a general idea of how this can be done programmatically.
So I went into digging and looks like it can be done. It wasn't even as difficult as I feared it would be, though I wouldn't say it was very easy either.
The main points are as follows:
I wrote an app that basically puts the site on the native Android lock screen. (Actually, I already had an app and I added this functionality to it, but that's less important. The main thing is that my method requires writing an app.)
So I guess this falls somewhere between the cases 1 and 3 above. I do need an app, but it's not a full-fledged custom lock screen, as detailed below.
This of course means that the method is more general, it works with any app, not just for displaying a site.
Set FLAG_SHOW_WHEN_LOCKED for the Activity window, as shown for instance here:
How to make our own lock screen in android instead of default lock screen
But I only used this flag, the other 3 mentioned in the link I didn't need.
Launch the Activity (if it's not running already) and set it on top before the device screen goes off, that is on receipt of the ACTION_SCREEN_OFF event. This way, the app is always visible when the screen goes off so next time it starts, Android will put it in front of the lock screen. (At least if it's the standard one; from the documentation it looks like it should be working with a custom lock screen too but I didn't test it. I guess it depends on how that custom lock screen is written. Anyway, I don't necessarily want my site on a custom lock screen, if the user has one he probably won't want to see my site in front of it).
This also means that the site will appear in front if the device is switched off then on, even if it's not locked. Which is what I intended.
Automatically start the app at startup via the BOOT_COMPLETED event
Capture the standard back key (which is allowed, unlike for the home key) and make it act like the home key when it would otherwise terminate the app.
I intentionally let the home key act normally. This of course means that after pressing it (which is the way the user exits the app and enters the device) the lock screen underneath is shown. Otherwise I would have had to deal myself with password-protecting the device, which is in no way something I want to do. There are a few drawbacks with this approach but IMO they're small. For simplicity's sake I chose to do it like this.
Besides, this way my app remains reliable, which it wouldn't have if I had hijacked the home key, no matter which way.
As said, this means that this is no full-fledged custom lock screen, just a way of putting the site over the default lock screen.
(update nov. 18) There's one more important point. As described so far, such an app could have a security issue. I'm not an expert so I'm not sure if it really does, and if so how important it is, but you can never be too safe. If the user can go unchecked to any site, when on the lock screen, it means that if the phone is lost and a bad guy finds it, he could go to a site that has dangerous code that could unlock the device. I'm not sure if it really could be done but I wouldn't be surprised. So, one good advice for anybody who writes such an app would be to severely (but reasonably) restrict Web navigation while on the lock screen.
These are the main points, there are a few other implementation details but I'll leave them out for the moment.
All this looks pretty standard and reliable to me, given that it's all in the official Android documentation.
I tested it on my KitKat device, plus on 2 emulators, one also with KitKat on it, the other one with the latest and greatest. Everything seems to work fine. Including the case when the device / emulator is password protected.
So I just wrote the app and published it on Google play. It's here:
https://play.google.com/store/apps/details?id=com.a50webs.intelnav.worldtime
Which means that now there is at least an app on Google Play which has this feature. It remains to be seen how well it will behave. I'll probably have to make minor corrections in the coming weeks, but other than that it should be fine.
Also in the coming weeks, maybe a month or so, I plan to put another app that will do this generally with any site, at the user's request.
(update nov. 18) I finally wrote the app and put it on Google play. It took a little longer than planned but it's ready. It's here:
https://play.google.com/store/apps/details?id=com.simionescu.vlad.weblock&hl=en
As noted above, when on the lock screen, navigation is restricted to the same domain, so that if a bad guy finds the phone he cannot go to some malware site and unlock it.
I have an Android app in the Play Store. In the last couple of days I've started getting bug reports about "black blocks in the settings screen". Unfortunantely I haven't been able to reproduce the bug on my devices, so everything I know comes from user reports.
I've got the following screenshots from a helpful user:
http://madscientist.pl/temp/bug0.png
http://madscientist.pl/temp/bug1.png
There's supposed to be white text on the tab headers, on the buttons and next to the radio buttons and seek bars. There should also be white horizontal lines separating the options.
The sizes of those black boxes that are visible (the rest is on the black background) correspond to the sizes of letters that are supposed to be there. The text on the two columns of buttons reads "Save" and "Load".
My app can be opened in two modes: live wallpaper and as a "regular app". The problem apparently exists in both versions.
Almost all bug reports describe another characteristic: the settings screen sometimes works correctly and sometimes it doesn't. E.g., sometimes opening the settings activity of the live wallpaper for the second time fixes the problem.
Another person wrote that it works correctly on the first application run only. After that, he has to clear the app data and then again it fails on the second run. So it seems that the bug manifests itself rather unpredictably.
I admit to not being a very good dev and that all the text is put directly in the layout files instead of in strings.xml. It was never an issue before, but just in case I'm in the process of establishing if putting the strings in strings.xml helps with one of the users.
The problem seems to be independent of the device. I've got reports from Samsung, Motorola, LG and Nexus users.
From what I've established so far, for at least one of the users the problem happens on both current and previous version of my app. The previous version was in the store since January 2015. The current version is a month old. I've been getting bug reports for just over a week now so this doesn't seem to be (directly) caused by some change I made to the app.
This led me to believe that the new Android version that has been rolling out recently (at least I've got 5.1 a week ago) is the reason. However I've got bug reports from a user who runs the app on 5.0.2 and 4.4.4.
The app is moderately popular and has a stable amount of downloads, so the fact that in the last week I've got a dozen reports of this bug, and before that I've never heard of it, leds me to believe that it indeed started happening over a week ago. So apart from the bug itself, it's really beyond my understanding what made it appear just now, if neither application update nor system update seem to be related.
I could provide more data, but the question is already terribly long. Let me know what else you think could be helpful.
So, this is an odd one.
I have implemented a custom ScrollView that allows drag and sort operation on a list of items by intercepting touch events. This works well enough on three out of four devices that I have tested on.
On Dell 7 tablet running 4.4.2, the behavior is really strange. The movement while dragging is rough. And in the middle of a drag, the Google Keyboard crashes. This happens irrespective of whether the keyboard is currently open or not. And no exceptions are present in my logs. The app continues to function as before - perhaps a bit more smoother - this happens once after the activity starts - on the first drag operation. After this, the keyboard and the drag-sort work as expected.
There were a few mentions of spell-checker events (not sure if they were indicative of an exception) in the System and event log included in the crash report. These spell-checker log statements were output right before the keyboard crash. So, I checked whether the spell check was turned on. The three devices on which the app functioned fine had the spell-check off. Only the Dell tablet had the spell-check on.
Next, I turned off the spell-check on Dell tab and the keyboard crashes stopped. This is very unusual, and I can't wrap my head around it.
Has someone experienced this behavior? If there exists a bug report detailing the issue, it'll be great if someone could point to it.
Thank you for reading. I did not include any code because I don't know what the relevant part(s) would be.
I do have a problem and have very little to go on. I'm about to release an App (created with Air for Android As3) on the Samsung App Store and just got a list of issues that have to be resolved after the app has been tested by samsung staff before the app could be released.
I did manage to solve almost all of the issues, but 1 very important one is beyond me. They say the screen turns/stays black, when returning after the device alarm interrupted the app. This issue practivally happend on all their devices, including a group including the phones I own (e.g. Galaxy S3).
I do have "OnDeActivate" and "OnActivate" listeners in place that are there to pause the app, disable sound etc. if it loses focus, gets minimized etc., yet I checked on my devices and I can't reproduce this error. Meaning if the app gets interrupted on my device by the alarm, I can resume it without any problems. no black screens.
So the question is: Is there any way for me to fix that at all? I do have to work within AirForAndroid AS3 so I guess possibilities are limited. Any clues where I can look? Any listeners to set, or is there a way to maybe "force" the app to reinitialize or refresh the display? Or to listen for the system alarm? Help would be much appreciated. Thanks in advance!
I am trying to overcome the same issue, I read somewhere that setting the stage quality to something else on both the activate and deactivate events might solve the issue.
So just set your stage quality to medium or whatever different in the deactivate and set it back to what it needs to be in the activate.
This should make AIR snap out of that black screen for the alarm (I hope)
An app of mine is with this fix is currently undergoing testing on the Samsung App Store.
I hope it fixes it.
Good news, the dirty fix of toggling the stage quality seems to have worked for Samsung, it has not shown up in their latest certification report of my app.
by the way, this is not for a stage3D app, that's different
It's for a GPU app
When the app loses focus on Android (goes into background) it will lose the context, which among other things mean that you lose all the created graphics, cached objects and like.
You didn't specify what kind of app it is. If you're using Stage3D, that means you'll have to recreate all your textures, and if you're on plain old displaylist, you'll have to recreate any bitmaps that were created at runtime, and redraw your screen at least once (so the vector graphics get redrawn too).
Now, if you're using Starling, for example, it can take care of recreating context for you (there's a flag for enabling that), although you'll still have to recreate dynamically created bitmaps.
I am having an app in the store which runs fine on most devices but on one particular
Samsung Galaxy S2 running Android 4.1.2 (version JZO54K.I9100XWLSS).
It crashes on startup without a crash-report from google or from crashlytics which i integrated. Its not actually a crash it just flashes the main activity a while until the phone shuts down:
A video of that behavior:
https://dl.dropboxusercontent.com/u/523370/20131004_115027%5B1%5D.mpeg
Its a device from a user, so I cannot debug it locally. (Is there something to get a live logcat stream from the phone over the air?)
Has anyone experienced such a "crash" on start only affecting one particular device?
I have a SGS2 where it works without flaws. Could there be any hardware reasons resulting in such a crash e.g. Memory issue.
I know this problem is not likely to be resolved without any further source code / crashreports, but maybe someone can point me in the right direction.
best regards,
Mike
Actually shoe rat saved my day!
Because shoe rat just commented on the case I am answering it for completeness.
The user enabled the option
"Do not keep activities" which lead to this strange behavior, because an activity was killed during the splash screen.
As a future reminder to myself I will get rid of the splash screen because its not holo-style anyway.
Cost me a lot of time to figure this out and i probably wouldn't have found it without your help.