I want to create a really big swap file on my Android phone or at least to try it.
System: Android 7.0
Phone: Samsung GALAXY S7 edge
Root: YES
I have already tried the ROEHSOFT RAM EXPANDER which works well but it allows me to create only max. 4 GB of swap file. I am talking about 20 GB or something like this. I know that it is crazy and may be unstable but I undergone every risk. I do not care about the speed. I would appreciate if you helped me and told me any guide how to do that. I undergone all the risks and the possibilites of crash of the phone. It is not my main phone so I do not care about it. I just need the RAM. Thanks everybody for help.
Related
Searched for a solution, didn't find anything helpful.
I have a GTX 970 and an i5 4690k OC 4.2 GHz.
The Emulator from Android Studio is lagging as hell and I don't know why.
Intel HAXM is installed, 4G Ram is allocated to the Android Device. I just can't find a solution. Btw. I don't think my processor is too bad since I can run 2 VMs at once and the Emulator works fine on my XPS 15 9560 (i7 7700HQ & GTX 1050)
Does anyone have an idea what to do?
Config:
Also tried using Software for graphics emulation, much more slower. Btw for reference this runs in the background and doesn't seem to resolve:
The SDK used
CPU Usage:
Also, I installed the AVD also on the same system on Hackintosh:
CPU: 10% and works smoothly
Cut the RAM way back. There is no Android device of note that has 8GB of RAM. Something in the 1-2GB range should be fine.
Cut the VM heap way back. For example, my emulator images use 48-128MB, not 8GB.
If those don't help, experiment with a lower-resolution emulator (e.g., Nexus 4 1280x768) and see if that changes your results.
Fixed it! I did a random windows update to Version 1803 and now the emulator works perfectly! Thanks for all your suggestions and answers!
also think that the RAM settings are at fault ...
in particular the heap size matching the total capacity.
the default settings, which should run smooth(er) are:
CPU: 4 Cores (while available)
RAM: 1536MB
Heap: 384MB
also check background processes once, in particular AntiVirus with on-access scanner, etc. (some people have 2-3 of them installed); one of them is enough and if present, disable it once for a test. the emulator ordinary is much less of a memory hog than Android Studio with Gradle can be. if everything fails, the screenshot shows that there is one bank available, which could take 2 DIMM. booting another system from external media might also worth a try, in order to rule out the current OS install. and I also have that "preparing for setup" on one emulator image; that's nothing to worry about.
Could you try changing the OpenGL ES Renderer to Desktop Native OpenGL
And OpenGL ES API Level to Renderer Maximum
This made my emulator very responsive, almost 2x faster.
Like this picture
Also it might be worth mentioning that I set both my camera's to none.
my first android game it's almost done, and I'm on the way to publish it on the play store.
Today I tested it on some friends phone and it worked on all except for a samung a5. On this phone the meshes flicker, apper and disapper and look deformed. This when playing game where I use a lot of frame buffer, in the main menu where there is a simpler animation everything look right.
The game is developed with libGdx and use some custom shader. I've tested it on 8 other different device without no issue (excepect for low frame rate on samsung galaxy tab s4).
I ask yours advise:
1) what should I start to check to find the problem with a5?
2) do you think I should delay the publication until the bug it's solved ora I should publish it excluding A5 ( or maybe all devices with similar GPU) from compatibility list?
My big problem is that at the moment I don't have the device with me (it's the personal phone of a friend of mine...) and probably I will have it for only a limited amount of time, so I want to be preparated to avoid to lock the device for too much time to my friend.
Thanks to all!
First, I'd make sure you don't have any OpenGL errors - add calls to glGetError and validate frame buffers and shader programs, you can do this without the device and adding extra asserts like this is always worthwhile (assuming you don't already have them). Next, try using the tools provided by the GPU manufacturer. In your case the snapdragon profiler. To minimize the time you'll be using your friends device, get the tools installed ahead of time and if you have access to another Qualcomm device, then use that to familiarize yourself with the software. With luck the cause of problem might become immediately obvious. If not, then it's just a binary search of disabling parts of your code until you narrow it down to a particular shader/draw call, then examine/tweak that to figure out what bit is going wrong.
That's a tough call. If it's a driver bug, then it might only occur on particular revisions. Some A5 devices might work if they're on different versions of Android from your friends device. That said, the A5 is relatively recent and Samsung/Qualcomm drivers tend to be pretty solid IME, so it's more likely an error in your code that happens to only be exposed on certain devices. Personally I would delay release unless your release strategy is timing sensitive, from the limited data you have, your game doesn't work on >10% of devices.
I know that question was already asked. But I'm adding some more details and asking more precise questions that can solve this problem.
Actually, when I start an AVD with 312 MB of RA it does manage to do it respectably (even if it's considered slow).
But when I ask for 512 MB of RAM, it's like it will never start at all (in fact never), and noticed that the AVD only works on a single core a 100%. Plus it populates the RAM quite quickly until it reaches around 175MB (5-10MB/s) and then slows down dramatically (250KB/s).
How can this happen and how can I do for preventing such RAM filling performance drops ? Or even set the AVD to use more than one single core ?
I run this on a Core I5, with 4GB of RAM.
Edit: Why so much downvotes ?
Problem solved: Templating from a Nexus 5 messed up everything, went to Nexus 4 and everything works like a charm.
a. Use the Intel system images available on the SDK manager.
b. Use this software by Intel to make your emulator run faster.
c. Use Genymotion.
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.
This question already has answers here:
java.lang.OutOfMemoryError: bitmap size exceeds VM budget - Android
(13 answers)
Closed 6 months ago.
I am developing an android app and as I read all around and learned for myself, I cant have a lot of images on the screen at the same time or I will get an exception.
The question is how many images or how many KB in images or how many layouts/images can I have at the same time in the screen.
I know this is not the only thing that has influence on memory, but I am looking for a number so I can plan around it.
Thanks
Daniel
Edit:
I just found this on the android dev site (http://developer.android.com/resources/articles/future-proofing.html)
Technique to Avoid, #3: Going Overboard with Layouts
Due to changes in the View rendering infrastructure, unreasonably deep (more than 10 or so) or broad (more than 30 total) View hierarchies in layouts are now likely to cause crashes. This was always a risk for excessively complex layouts, but you can think of Android 1.5 as being better than 1.1 at exposing this problem. Most developers won't need to worry about this, but if your app has very complicated layouts, you'll need to put it on a diet. You can simplify your layouts using the more advanced layout classes like FrameLayout and TableLayout.
I guess this can be my problem.
When it says 'broad' , is it saying on the last level ?
Thanks
Daniel
This answer has 2 parts
1) its not how much images the screen has, but being carefull on cleaning everything up when finishing the activity
2) (Future-Proofing Your App)
Technique to Avoid, #3: Going Overboard with Layouts
Due to changes in the View rendering infrastructure, unreasonably deep (more than 10 or so) or broad (more than 30 total) View hierarchies in layouts are now likely to cause crashes. This was always a risk for excessively complex layouts, but you can think of Android 1.5 as being better than 1.1 at exposing this problem. Most developers won't need to worry about this, but if your app has very complicated layouts, you'll need to put it on a diet. You can simplify your layouts using the more advanced layout classes like FrameLayout and TableLayout.
Daniel
The amount of memory varies from device to device and the amount you have to play with depends on what else the system is doing at the time. Your best bet is to not even come close to running the system out of memory if you can help it. What are you doing that you need that many images on the screen?
This thing is depends on the HEAP size of phone .
so if your application acquire more heap then phone provided then it may be create a problem .
the new generation android device contain .here is the list of some
HTC Wildfire (2.2.1) = 16MB.
HTC Wildfire S (2.3.5) = 20MB.
HTC Salsa (2.3.3) = 20MB.
HTC Desire (2.3.3) = 32MB.
HTC Desire S (2.3.5) = 32MB.
Samsung Galaxy S GT-I9000 (2.2) = 48MB.
Samsung Galaxy R GT-I9103 (2.3.5) = 64MB.
Samsung Galaxy Y GT-S5360 (2.3.5) = 64MB
so there is not certan solution for it , but you can try to optimize the the bitmap size .
for example recycle the bitmap after use it . or make another using bitmapFectory deoeed from sampleSize .
IF you are using a emulator then you can create a device which contain more heap size to Add new extra hardware configure in your avd manager as VM heap size = 32 or up .