Android Question FAILED TO COPY TO 'data/local/tmp/ACIM.apk': No space left on device

[TheWind777]

I am trying to install the App to an older phone.

I have Link2SD v5.4 App running so I can use a large SD card. This allows the tiny phone to have a great amount of storage space.

However, when I use Memory Cleaner App on the phone it says:
Used: 100.42 MB
Free: 260.66 MB

Is there some App which could extend that amount of MB to include the SD Card, so it doesn't have such limited space?

Next, the ACIM.apk in the B4A Objects folder is 148,662 KB in size.

So, it probably copies it over to the /data/local/tmp/ folder on the phone, leaving 111 MB

Then, the install is more than 111 MB in size so it fails.

Is there any way to change the folder that it installs the tmp APK to?

When I use FTP Server and copy the apk to the SD Card myself, then use Root Browser to Install the APK it works fine.

Is there a permission I can set in the manifest, or otherwise, to have B4A save the APK to the SD Card instead of the phone's tmp folder so it can put the APK there as it is installing the package and not run out of room?

 

[Erel]

Have you set #CanInstallToExternalStorage: True ?

 

[TheWind777]

Yep.

However, I might have no need to worry about it any more. I had a lot of folders in the Files folder where I was keeping all my construction work stuff (huge PSD files with layers, etc). When I moved those out of the Files folder, even though none of those folders were added to the 'Files' section... the size of the APK dropped from a whomping 148,662 KB to 11,306 KB.

I had never looked to see what the size of the APK was, before. Since I am currently coming to completion, size of the APK became a concern (also, I'm trying it out on two very old phones that are extremely limited in size and old Android operating systems just to make sure it will have wide range of compatibility). Both phones only have 300 MB, total, of RAM available (even though they have almost no Apps installed). They're both TracFones (one is an LG and the other is a Midnight).

So, apparently, those folders (or something, at least, that was huge) was being added to the APK because I had folders inside the Files folder that had nothing to do with files to upload.

I had just assumed that only the files included in the checkmarked area were included. I didn't realize that folders that I might have in the Files folder that had nothing to do with anything would also be added. Whoops.

Therefore, the need for worry about size has suddenly disappeared.

I wonder why it was using the tmp folder, though... if I had
#CanInstallToExternalStorage: True

set in Project Attributes?

 

[Erel]

If your app includes a widget or a service that starts at boot then the app will be installed internally. It is possible that there are other cases where the OS decides to install it internally.

 

[TheWind777]

If your app includes a widget or a service that starts at boot then the app will be installed internally. It is possible that there are other cases where the OS decides to install it internally.

Nope. Doesn't start at boot.

Two questions...

First, is there anything else I can do to make the size of the APK be really small. I just deleted a bunch of code and found that it didn't make the APK any smaller at all. Does getting rid of comments do anything to the size of the APK?

Second, is there a library call or variable I can use which shows the version number of B4A?

 

[Erel]

Does getting rid of comments do anything to the size of the APK?

No. Deleting code will also have a very minor effect. Check the files in the Files folder. The files usually take the largest portion of the APK.

Second, is there a library call or variable I can use which shows the version number of B4A?

At runtime? No.

 

[DonManfred]

At runtime? No.

Maybe a good suggestion for a new feature in B4A 4.0

 

[Erel]

Why is the B4A version important at runtime?

 

[Informatix]

Then, the install is more than 111 MB in size so it fails.

If your application uses big PNG files, you can reduce their size with Free PNG Optimizer (lossless operation) or convert them to JPG if they are fully opaque. If your app contains other data, you can zip them and put the zip in the assets, then unzip this archive to an external folder when first launched.
I recently discovered a thing with my new phone: your internal storage has quotas but these quotas can't be seen anywhere in your device settings. So you can have 400 MB free on your device and be unable to install an app of 400 KB on it. The reason was, in my case, because I reached the quota for media files. I removed just one movie (new free size: 401 MB) and I was able to install the 400 KB app.

 

[TheWind777]

Yep. Besides... 11 MB is pretty small. 148 MB wasn't.

Yeah, having a function that returns the version number of B4A during run-time would be a nice addition; but just adding it manually won't be that hard.

 

[TheWind777]

If your application uses big PNG files, you can reduce their size with Free PNG Optimizer (lossless operation) or convert them to JPG if they are fully opaque. If your app contains other data, you can zip them and put the zip in the assets, then unzip this archive to an external folder when first launched.
I recently discovered a thing with my new phone: your internal storage has quotas but these quotas can't be seen anywhere in your device settings. So you can have 400 MB free on your device and be unable to install an app of 400 KB on it. The reason was, in my case, because I reached the quota for media files. I removed just one movie (new free size: 401 MB) and I was able to install the 400 KB app.

 

[TheWind777]

Yeah, I just went through every PNG one-by-one, loaded them into Photoshop and resaved them as lossless compression (it's just a checkmark with Photoshop). One thing that I thought was pretty nifty that I never knew was Windows 7 remembered automatically and moved to the next file when I would double-click one file, save, and the next time I would look in the folder the high-lit file had moved to the next one. Finally the operating system is starting to have the teeniest bit of AI built into it. That, in the end, saved about 4-5 Meg in the resulting APK.

However, when I removed unused code that was commented-out. Absolutely no size difference. It's interesting seeing what one does and the resulting APK size afterwards.

I was astounded the difference in size of the APK by just moving my work folders out of the Files folder. Although no files had been included in B4A from those folders the size of the APK rose from 11 MB to 148 MB for unknown reasons. It must have been automatically adding certain files to the APK from those folders without my knowledge. Moral of the story... don't keep your work folders inside folders inside your Files folder because it is handy to do so.

Compilation time greatly extends also. When I moved the folders out, it compiled really fast. It must be recursively searching the folders for something (and adding things automatically when it finds whatever it is looking for). About the only thing that was in any of those folders were images in PSD, JPG and PNG format; so it must be looking for PNG files for some reason and automatically adding them, weird. Anyways, don't keep any work folders inside the Files folder.

 

[Informatix]

Yeah, I just went through every PNG one-by-one, loaded them into Photoshop and resaved them as lossless compression (it's just a checkmark with Photoshop). One thing that I thought was pretty nifty that I never knew was Windows 7 remembered automatically and moved to the next file when I would double-click one file, save, and the next time I would look in the folder the high-lit file had moved to the next one. Finally the operating system is starting to have the teeniest bit of AI built into it. That, in the end, saved about 4-5 Meg in the resulting APK.

However, when I removed unused code that was commented-out. Absolutely no size difference. It's interesting seeing what one does and the resulting APK size afterwards.

I was astounded the difference in size of the APK by just moving my work folders out of the Files folder. Although no files had been included in B4A from those folders the size of the APK rose from 11 MB to 148 MB for unknown reasons. It must have been automatically adding certain files to the APK from those folders without my knowledge. Moral of the story... don't keep your work folders inside folders inside your Files folder because it is handy to do so.

Compilation time greatly extends also. When I moved the folders out, it compiled really fast. It must be recursively searching the folders for something (and adding things automatically when it finds whatever it is looking for). About the only thing that was in any of those folders were images in PSD, JPG and PNG format; so it must be looking for PNG files for some reason and automatically adding them, weird. Anyways, don't keep any work folders inside the Files folder.

Yes, it includes everything found inside your Files folder.

 

[TheWind777]

If your application uses big PNG files, you can reduce their size with Free PNG Optimizer (lossless operation) or convert them to JPG if they are fully opaque. If your app contains other data, you can zip them and put the zip in the assets, then unzip this archive to an external folder when first launched.
I recently discovered a thing with my new phone: your internal storage has quotas but these quotas can't be seen anywhere in your device settings. So you can have 400 MB free on your device and be unable to install an app of 400 KB on it. The reason was, in my case, because I reached the quota for media files. I removed just one movie (new free size: 401 MB) and I was able to install the 400 KB app.

Actually, zipping files and then unpacking them in that manner would increase the amount of used RAM in the end because you'd then have the zip archive size and the unpacked size combined (same problem as me needing room for the APK file in the tmp folder, and the unpacked size). During the unpacking, you need to put the file somewhere (or in this case, keep the zip file in the assets folder because you can't delete stuff in the assets folder).

Only if Android had an automatic unpacking feature (or the file had the automatic unpacking feature built-in such as EXE Packers have) would that save you space.

That would be great if Android had an auto unpacker for HTML code. HTML code is rather wasteful of space and that is a great amount of the 11 MB. I don't believe there is any auto android HTML unpacker feature built-in to Android.

HTML code is necessary, however, because if you want color and variety of placement in a window, plus the ability to zoom in a window - a WebView has it all and is generally a much better choice than using any other type of window (particularly if you know HTML, or use the free KompoZer program which doesn't crap-up the code by adding undecipherable junk like most HTML editors do).

RichStrings are a helpful, yet awkward way, to add color and variety to other panel types; but using HTML for colorful, varied, pages that can automatically zoom and pan...

In my case, I am manipulating large text files (about 1000 of them); so all I have in the Files folder are TXT, HTML, PNG and JPG, MP3 and TTF. (The biggest files are the TTF files and HTML files. I allow them to choose from 11 different fonts and 85 sounds). The sound files are kind of big.

 

[Informatix]

Actually, zipping files and then unpacking them in that manner would increase the amount of used RAM in the end because you'd then have the zip archive size and the unpacked size combined (same problem as me needing room for the APK file in the tmp folder, and the unpacked size). During the unpacking, you need to put the file somewhere (or in this case, keep the zip file in the assets folder because you can't delete stuff in the assets folder).

Are you sure that you don't make a confusion between the RAM (the volatile memory where are loaded the system, the applications to run, and their data) and the flash memory (the memory where all files are stored, seen as a non-volatile disk) ?
My suggestion was to unpack the files to your external folder, so you can have your APK in the internal folder and its data in the external folder of the application. The zip file is not loaded entirely in memory when unpacked, so it does not occupy its file size in memory. In fact, only a small part of the file is loaded one at a time (buffered IO).

The sound files are kind of big.

You should consider reducing them to mono. Unless someone wants to hear them through an headset and you want to maintain a high quality...

 

[TheWind777]

Are you sure that you don't make a confusion between the RAM (the volatile memory where are loaded the system, the applications to run, and their data) and the flash memory (the memory where all files are stored, seen as a non-volatile disk) ?
My suggestion was to unpack the files to your external folder, so you can have your APK in the internal folder and its data in the external folder of the application. The zip file is not loaded entirely in memory when unpacked, so it does not occupy its file size in memory. In fact, only a small part of the file is loaded one at a time (buffered IO).


You should consider reducing them to mono. Unless someone wants to hear them through an headset and you want to maintain a high quality...

Yep, got them all at mono.

 

[TheWind777]

Are you sure that you don't make a confusion between the RAM (the volatile memory where are loaded the system, the applications to run, and their data) and the flash memory (the memory where all files are stored, seen as a non-volatile disk) ?
My suggestion was to unpack the files to your external folder, so you can have your APK in the internal folder and its data in the external folder of the application. The zip file is not loaded entirely in memory when unpacked, so it does not occupy its file size in memory. In fact, only a small part of the file is loaded one at a time (buffered IO).


You should consider reducing them to mono. Unless someone wants to hear them through an headset and you want to maintain a high quality...

Well, I compressed it down to 9477 KB. Even if you had an extremely slow CenturyLink 1.5 Mbps it would take 49 seconds to download. With a more reasonable 10 Mbps it would take 7 seconds.

I converted all the big files to Photoshop's 'Optimized for Web' .gif format with no apparent loss. Some I did at 16 colors and more important ones at 32 colors. When I tried JPG I got the smallest files; but severe pixelization squares. Android does much better at interpolating sizes with GIF images than JPG.