ideas
ideas copied to clipboard
open-source-ideas
Package manager for Android
Project description
Android software is damn bloated. Nearly every package includes Android Support Library, lot of them include http clients and other useful libs. Nearly every release consumes more and more space than the previous one.
It may make sense to
- have a package manager for these shared libs
- remove them out of apks on installation
- transparently (for an app) load them from packages
- these manipulation should preserve packages signatures
Though the idea may be completely junk: it is expected that there will be no Android in 2021 because of Fuchsia.
Relevant Technology
Android, ART, Xposed
Complexity and required time
Complexity
- [x] Advanced - The project requires the user to have a good understanding of all components of the project to contribute
Required time (ETA)
- [x] Much work - The project will take more than a couple of weeks and serious planning is required
-
Android is undergoing changes. As you mentioned, it might be replaced by Fuchsia. So there's no futurism in doing such a project.
-
The only components applying to such an idea are architecture-independent resources, native libraries and maybe Java libraries.
- For architecture-independent resources, it's doable.
- For native libraries and the dex part of it, you don't know what they actually contain, which version of which libraries they are. Are those libraries even public software or native components of the app itself?
-
Contrary to the mother Linux, Android has chosen to have this limited snap-like sandboxed approach to software installation. Very few developers have made use of the native shared library feature of the Android platform.
-
See https://stackoverflow.com/questions/42998083/setting-androidextractnativelibs-false-to-reduce-app-size
-
To reduce an APK size, one option that helps is to remove all native libraries of foreign architectures.
For native libraries and the dex part of it, you don't know what they actually contain
It doesn't matter much. One usually can replace version of a dependendency to a newer one without breakage - developers keep them compatible to each other because having them incompatible means people will have to do manual changes when upgrading version. Noone wants it.
For not so frequent cases of incompatible versions it may be possible to store multiple versions. It will still consume strictly not more and usually less space than duplicating that lib for multiple apps.
Contrary to the mother Linux, Android has chosen to have this limited snap-like sandboxed approach to software installation.
IMHO: self-sufficient packages are evil.
To reduce an APK size, one option that helps is to remove all native libraries of foreign architectures.
Yes, but they are usually removed. Devs usually ship different apks for different archs.
@KOLANICH
It doesn't matter much. One usually can replace version of a dependendency to a newer one without breakage - developers keep them compatible to each other because having them incompatible means people will have to do manual changes when upgrading version. Noone wants it.
It matters a lot. You don't know what a native library actually contain. That may be a mixed compilation of the app's own native code along with different versions of third-party libraries. Also, an app's dependencies are indeed not forward nor backward compatible, most of the time.
For not so frequent cases of incompatible versions it may be possible to store multiple versions. It will still consume strictly not more and usually less space than duplicating that lib for multiple apps.
This is so core a change that it has to be supported by the Android itself and implemented by the developers. Even if you wanna remove some stuff from a installed apk, the device has to be rooted. But if the device is rooted, there's no storage problem as you can move even protected system apps to the SD card.
Yes, but they are usually removed. Devs usually ship different apks for different archs.
I may have decompiled APK files more than 2000 times; And I've frequently seen many unnecessary resources of any type bundled in a single apk.
I think of a command-line tool for the Android OS to shrink all installed APK files to the minimum of what that is essential. Any interest?
You don't know what a native library actually contain.
Why? There are so files. If different apks use the same so files, they can be identified by hash. Also keep in mind that I meant not only so files, but java code too.
This is so core a change that it has to be supported by the Android itself and implemented by the developers.
I wonder if XPosed can be used to implement that.
Even if you wanna remove some stuff from a installed apk, the device has to be rooted.
Definitely. Users of non-rooted devices are out of scope.
But if the device is rooted, there's no storage problem as you can move even protected system apps to the SD card.
1 Not having a package manager is a problem itself. 2 having an external sdcard is not a solution of the problem of apps consuming space which is not necessary should be consumed. It doesn't solve the problem of bloating, it just sinks it in gibibytes.
I can make easily android package manager because I have made small package manager for my company but I have no resource for the deployment of package manage I need AWS ubuntu instance. if anyone wants with these resources can collaborate with me
@nomi9995 the idea is that the libs are shipped from the apks that are installed. I mean the apks are distributed currently with all the dependencies within apks. We need to identify the individual libs within them and extract them, if there is no libs installed, or just discard, if we already have the libs. Deduplication. And then repackage apks and do it automatically on instalation and updates. And when an app is loaded, all its parts should he loaded. So no huge servers are needed, maybe 1 GitHub/GitLab repo in a worst case.
like NPM really sucks. There is no need in a yet another malware-plagued package manager. This issue is not about it.
@KOLANICH NPM is best to package manager now. It opens the way for the developer to make own packges
If you're looking to reduce disk usage on your own system, you may be able to get something like fdupes/jdupes to just create replace duplicate libraries with hardlinks. That won't help with the APK size, but it should certainly help with the files that have been copied out of the APK.
That won't help with the APK size, but it should certainly help with the files that have been copied out of the APK.
Thanks. But the most of android apps don't contain native libs, but have a lot of java dependencies bundled. And the native libs bundled are rarely of the same versions and are built non-reproducibly, so thir hashes very likely to be different.
May I suggest two things, the first, is take a look at puppy package manager and see whether it's possible to replace the remaining bash/ash with (just) sh. After this has been done, the package manager should work on android, though it'll use something else instead of apks, but will still support debs. This may not seem like a brilliant idea or it may not seem like it helps you much, but it is something I am considering for myself in future.
The second thing, is you may wish to take a look at my repository for creating an android application using autotools, it's very proof-of-concept, but should show you how to package an apk fairly seperate from the android stack. https://github.com/publicsite/package-android-ndk-apk-autotools
@publicsite, thanks for the ideas. Though they are offtop in this topic, they may be relevant.
- About debs on Android. Busybox is available for Android (there are multiple apps installing busybox into rooted phones) and it contains an impl of
dpkganddpkg-deb. - I'd prefer to create android apps using CMake (and packaging using CPack), autotools have terrible usability and are damn damn damn slow. But I was surprised it is possible to create an android app without JVM code. Thank you for the info.
I also have a yet another idea in the backlog driven by my needs. Here it is: #339