I have around 10 video files in the sizes of 10 MB each. I want to have them inside the /data/user/0/org.my.app/files. Somehow they need to be included in the .apk and installed here.
Right now they are living in this structure in Qt project:
DISTFILES += \
assets/video/video1.mp4
The goal is to be able to play the videos using
Video {
source: appPath + "/assets/video/video1.mp4"
}
The ideal way is just using .qrc but it has been problems before when putting videos there.
With video, it's usually impractical to try to make it a resource since the size of the QRC will explode and result in long compile times and a large executable.
I've had luck delivering videos with a Qt Android app by using the native Java AssetManager: https://developer.android.com/reference/android/content/res/AssetManager
You'll need to use a CustomActivity in Java-land and integrate with it using JNI as demonstrated here: https://doc.qt.io/qt-5/qtandroidextras-customactivity-example.html
Or as #splaytreez points out you can use Qt's builtin support for Android Assets as documented here: https://doc.qt.io/qt-5/porting-to-android.html
Also, depending on the size of your video and what it does to your APK size, you may want to use the AAB bundle as discussed here: https://developer.android.com/guide/app-bundle/
Related
i just exported my game to use Play Asset delivery following this guide:
https://docs.unity3d.com/2021.1/Documentation/Manual/play-asset-delivery.html
in short
build app bundle enabled
split application binary also checked.
The exported aab size is 311mb and when uploading to google play it says:
base ----install_time ---30.1mb
UnityDataAssetPack ----install time ---264mb
But then when i download the app in any device, the file size is 846mb, more than double the expected size. Also it tries to download all at once, i thought that the dataassetpack was downloaded after the base one.
i'm using Unity 2021.1.16f1
Do you know any cause for this to happen, and how to fix it?
thank you very much!
You are comparing a "download size" to a "size on disk":
The size you see in the Play Console corresponds to the download size, which is compressed.
On the device, you see the size on disk where the data is stored uncompressed so it can be directly rendered without having to keep two copies of the same data (one compressed and one uncompressed), so that explains the discrepancy.
It seems that you have configured the modules to be install-time so they will be installed as part of the initial install. If you want them to be installed while the user is starting the game, you should configure them to be fast-follow. If you want to manually download them using the Play Core API, you should configure them to be on-demand. This is all explained in the page you linked in the Managing asset packs at runtime section.
That page also links to the Google documentation on the topic, which has a dedicated section for Unity -- which would be too long to copy here, so have a read and come back if you have more specific questions.
If you're only using Unity marking the AAB output type in the build settings, and not using Google's API to do your stuff via script, then it's correct. Unity has a bug when assembling bundles and will simply (at least) double the size of your app. Things will be doubled in your AAB, you'll see the stuff you had in streaming assets in split apks and also inside the base.apk. Unity's way is not reliable, it's quite wrong and Google's plain way for Unity also is not perfect, it will not work for every single project. I was able to get the hang of it, but in the end I wrote our own tool to create the asset packs, created our runtime implementation to use the API and also our build procedures to be called by our custom build class.
My suggestion is, squeeze the docs here https://developer.android.com/guide/playcore/asset-delivery/integrate-unity?language=api and build your custom solution.
I'm developing an app which creates x264 videos with the following library:
com.arthenica:mobile-ffmpeg-full:4.2.2.LTS
but the result apk file is too big (~71mb), so I tried:
com.arthenica:mobile-ffmpeg-min-gpl:4.2.2.LTS
and this way, as the library downloads only a few codecs -included the ones I need- apk size was reduced to ~49mb, what is much better, but still looks too big to me, so I'd need to know if any of you know a better way to reduce apk size, because people generally refuse to download such big apps
Regarding the rest of the app (drawables, resources and so) they're well optimized, because if I remove this library and rebuild, the size of the app drops to 10mb
I was reading this question:
FFMPEG Android Library Increase Size
and user S.R suggests to compress all cpu architecture models in one archive file and extract target cpu lib based on cpu model on app's directory and load ffmpeg from there, but I really don't know how to do that.
I'm checking my app's folder structure and noticed there are this next folders regarding ffmpeg lib:
arm64-v8a => ~16mb
armeabi-v7a => ~29mb
x86 => ~17mb
x86_64 => ~21mb
But not sure if I could remove any of them, and as you can see armeabi-v7a is the largest.
As per your requirement, FFmpeg is the best option to so much of video processing task but the problem with FFmpeg is it will increase the size of the app. So I will suggest you to compile this FFMPEG library in your project, it also has many inbuilt functions like add music, add image on Video etc. It will definitely help you with your work as well as size is also very small ~11mb.
You can use Android App Bundle (aab) to reduce app size
further.
use
implementation "com.arthenica:mobile-ffmpeg-min:4.4.LTS"
according to documentation
I was working on a lightweight pdf viewer, and I wanted the size to be of the range of 5 MBs,
I am using mupdf , but the compiled .so file itself is around 16.6 MBs,
Is there a way to compile mupdf with only pdf support and not the others like xps, images, etc.
Like this app on google play, the file of .so file is just 3 MBs
https://play.google.com/store/apps/details?id=de.geraldthaler.octopuspdf,
Any help will be greatly appreciated.
I figured, It was because of the font packs,
compiling without extra font packs generates very small .so's
If this is still relevant:
There is a configuration file In MuPDF source that lets you throw out features before you generate the library, called config.h located in directory mupdf/include/fitz.
By setting the appropriate #define statements, XPS, EPUB, etc. can be opted out. The biggest space saver is however opting out certain fonts. In essence you can restrict your library to PDF's Base-14 (Helvetica, Times-Roman, Courier, Symbol and ZapfDingbats) fonts. You also can opt out support for various image format support.
Taking all that together should bring you down well below 5 MB.
I am working on an app where we are using lots of libraries to provide funtionalities like reading PDF,docx,ppt etc also we have a youtube player and many more other libraries.
Due to the design of our app, we are using lots of resources to design UI(resources is about 22 mb). We are using these images in layouts (which are lot if you ask).
I checked to see whether we can go down on using Background images, but more we strip them, our client asks for more features to integrate in the app which again increases the size to more then 50 MB (Google play limitation as mentioned here Google play expansion file setup link) .
I am looking for a solution where I can somehow remove the libraries while compiling the app to keep size under limit of 50 MB and put it in expansion file (I know this seems to be a problem, cuz I don't know how I will compile the app without those libraries) and load it on run time .
I am very confused here, Can some one help me here ??
I am using vitamio framework to play audio on android.
The framework consists of a library file libarm.so The file is very big (5M), which makes my apk very big.
I delete file and compile my app, and still running fine.
I am wondering is it safe to just delete the file?
It contains some CPU-specific highly-optimized code that is used to improve the performance of some operations, like decoding of certain types of multimedia streams (ffmpeg uses it and I'm not sure if something else does too).
The library is actually a 7zipped pack of several libraries, built for different ARM architectures (ARMv6, ARMv7, etc.), thus its size.
These libraries are extracted to your device the first time you run your app. If you remove them and run your app successfully, it is most likely because they have already been extracted. Clear you app data, and try it again.
If the app doesn't crash when you delete it (and have cleared your app data), it means that you're just not using code that utilizes libarm.so APIs, so, unless you plan to add more multimedia support to your app, it is safe to leave the library out of it.