Ever since my Asus Transformer tablet was upgraded to Jelly Bean, I find that app and widget uninstalls are sometimes excruciatingly slow, as in taking several minutes instead of seconds. Could there be a reason for this?
The reason I'm posting this on Stackoverflow is that the apps I'm having the most trouble with are my own developed apps! As you know, when switching between debug and release builds of an app, you have to do an uninstall due to the different signing keys, so I do this on a regular basis and it's getting very annoying. Thanks for any hints on where to look for a solution -- if any.
I had this issue once, though it was in ICS and not Jelly Bean. The problem in my case was Google's app "Currents" which generated thousands of files as part of its cache. It took FOREVER to uninstall anything, or even get the size of any installed app because Android had to chug through all those thousands of files. Google has since fixed Currents, by the way.
So, I would guess that it's a similar issue, one of your installed apps is going nuts with creating files. If you open your app list and it takes a long time for the sizes to show up, that's further evidence that it's the same problem.
I had the same problem. In my case it was caused by SoundCloud's stream cache. After deleting it everything works fine again.
Same problem, also identified by extremely long time to calculate size of apps. In this case it was Google Earth App generating thousands of files (over 22000) on the local drive. Uninstalled that App
and it was fixed.
Related
So this is a new type of issue I am currently facing, Recently I ran an APK of React Native Application I recently built on my system. After running that APK successfully. I started facing some issues regarding my phone's ** sound key **.
I tried restarting the device [Samsung], So it stopped showing the 1st issue. But after a few days a 2nd issue arrives.
1st issue => The volume up button stops working manually and starts increasing the volume automatically.
2n issue => Now whenever I write a new Text Message to someone it automatically starts increasing the font size of the text.
I gave a reboot to the device and even formated it, but nothing helped.
I want to know if it's a software side issue or hardware? So that before submitting the device to a Samsung store, If it's a software issue and if I can fix it. It will save me some bucks.
I actually solved this issue and that was due to the Hardware issue that has happened to my Android Samsung device and I researched it.
This type of issue was very common with users having that old version of smartphones and that is why new design keys for power and volume were introduced in most of the new smartphones which were launched in later 2016. This has actually reduced the key issues and if in case there is an issue, now it is easier to fix it since the keys are separated from the board as it was used to be earlier.
Also, some useful sources if someone is facing a similar issue in their old version android devices.
Volume Slider.
Volume button not working
So I am one of several developers developing a GPS-app with the help of HERE SDK for Android.
This is a project that has been in the making for some time and it has been a somewhat smooth ride, until yesterday.
We have a couple of tablets to test our app with, and yesterday when building on the Samsung Galaxy Tab A(2016) the routing always gave us "GRAPH_DISCONNECTED" as an answer.
It doesn't matter what route I try. From current location. From a set location. The destination doesn't matter either.
So we have a CoreRouter.Listener that overrides the onCalculateRouteFinished-method and no matter what I do routingError seems to beceome GRAPH_DISCONNECTED.
I have tried to uninstall the app and install it again. Same result.
I have tried deleting the cache for the app. Same result.
The weird part? It has been working on the tablet for well over a year.
And if we use any other tablet, like the Xperia z4 tablet there is no problem with the routing.
Okay, so problem found!
Apparently, we had the wrong settings for the vehicle. It was too big to go from the positions we tried with, and that's why HERE couldn't make a valid route.
The strange part is that this route has worked with those vehicle settings before. So some construction must have come up all of a sudden that stopped me from making the same route.
A week ago,I developed a app and published to google play.
App Link
This app use camera and activity-alias . It works fine in my phones(S1,S2,New One,Sony Xperia v). But after i published to google play , i found many problems,like HTC one x camera or HTC butterfly activity-alias not working in my app . I dont have these phones ,so its hard to debug .
Is there a good way to solve this situation ? I used some test websites like appThwack and Keynote. But it only response me error message, I am hard to debug too,because it need to upload apk to test(spend long time).
I have found that with Android getting feedback from users on their specific device in inevitable, and unless you have those devices to test on beforehand you won't know until someone tells you.
Android is on so many devices with so many different screen sizes and hardware manufacturers it can be very difficult to get it working correctly 100% across the board. Knowing what devices have the issue helps point in the right direction, but nothing beats testing on the actual device.
Try to use Android Studio. You can preview your app for all screen resolution in one shot. For specific screen relotions and density, create an AVD. I think for independent developers, this is the best way (Considering your app runs on Emulator :-))
I'm testing on an HTC Sensation, running android 4.0.3.
I'm publishing using FlashDevelop 4.0.3 and using the Air Mobile AS3 App template.
All the application does is display a Rectangle using:
this.graphics.beginFill(0x00FF00);
this.graphics.drawRect(0, 0, 100, 100);
Just so I can see that its actually publishing something.
The app runs correctly if I publish to the desktop, however when I switch to publishing it to the phone, the problem I'm facing is that the application publishes and runs on the phone, but only for a few seconds.. usually about 4 seconds and then it crashes out.
The really weird thing is that it was working fine about a week ago.. I'm not sure what's changed since then, but yeah it started happening this morning, I tried everything I could think of... including stripping everything out of the app and also doing a factory reset of my phone... nothing seems to have helped...
has anyone else had this problem? or have any ideas on what might be causing it or how to fix it? any help would be greatly appreciated.
Cheers
Update:
it seems changing the render mode to "auto" instead of "direct" stops the crashing, which is great, however if you need to use direct for stage3d content this doesn't really help. anyone else having this issue?
Can you post the source code of your application? I do too have HTC Sensation but my firmware version is 2.3.6. It would be interesting to test it.
I just updated my XPERIA ARC to ICS and now I'm having problems with AIR apps as well. Seems the app is not getting the Click/Touch interactions. Some InteractiveObjects like TextInput gets the click and focus as it should, but Buttons are not working. And I'm using latest Flex/AIR sdks...
But I'm pretty sure we are in Adobe/Apache hands until they update the AIR with a fix.
Developed a application of size 40MB. I need to test it for all screen support but the android emulator really a bad choice(I feel... ). It gives Insufficient memory error almost every time). How developer test their application?
One more Question
I have designed app for four different layout(normal,small,large and xlarge). Will every device(In future) satisfy these layout params?
And i faced a real problem that i tested my app in Sony xperia minpro(Small screen 240*320 2.4inch) and in Samsung galaxy 5(smallscreen 240*320, 2.8inch) but the layout is overlapping in samsung device. This can be a serious problem , actually we cant check our app in every device.. that is impossible too.
TIA
40MB is way too big for an Android application. Many users will have problems installing the app on their devices. You should consider moving some resources out of the application and downloading them either on demand or on first app run.
The list of layout types (normal, small, large, xlarge) is definitely not final, for there quite possibly will be even larger screens (xxlarge) or tiny ones (xsmall?).
Developed a application of size 40MB. I need to test it for all screen
support but the android emulator really a bad choice(I feel... ). It
gives Insufficient memory error almost every time). How developer test
their application?
You can configure the emulator with any amount of memory you wish, including an emulated SD card so memory shouldn't be a problem. However, 40MB is quite big so you may be hitting the package size limit.
One more Question I have designed app for four different
layout(normal,small,large and xlarge). Will every device(In future)
satisfy these layout params?
You're asking us to predict the future - there's no way we can know what Google are planning if they haven't already announced it though I would suggest that there will never be a commitment to keep screen sizes or resolutions static - technology constantly evolves and specs that are OK for today, will not be OK for tomorrow.
I have seen dictionaries weighing in at 40Mb, best practise is to download the database as a separate file. Some graphically intensive games approach that size. If you want to emulate many Android devices make sure your PC is up to snuff and you have the latest SDK.
How developer test their application?
You do not have so many choices: you have to use as many (and different) physical devices as you can, from different vendors and technical specifications (screen, etc), to try to detect as many specific bugs as possible.
This is difficult, as you are often limiten to a few physical devices.
To give you examples, I recently struggled with the Camera, for a bug happening with Motorola Defy only. I am currently struggling with the Camera, but only for Samsung Galaxy this time.
When you find a specific bug, try to fix it "the general way": instead of detecting the vendor/version of the device to write specific code for it, try to enhance your code in a way it will work for all tested phones. So far, I never had to write anything specific to a given device. The bugs I encountered were always tied to a permissivities or particular cases that could be handled by making the common code more complete or resiliant. Let's say by "making as less assumptions as possible" knowing that we tend to make assumptions without meaning it.
On top of testing on as many physical devices as possible, create emulators. You can parameter them to have different screen layouts, different embedded hardware, memory, etc. And on top of the default emulator that comes with the Android distribution, you also have emulators provided by the devices vendors and that reproduce the specificity of these devices. For example, Samsung released a Galaxy Tab emulator. Sony Ericsson released a EDK Cellphone emulator. You can get them thru the regular android distribution update workflow.
Will every device(In future) satisfy these layout params (normal,small,large and xlarge)?
Yes, as Android distributions are backward compatible. Any of these layout will still be supported in the future, but may become 'deprecated' (so not recommended, but still working), and new layout types will certainly be created.