Background
I have an Android app which uses native ARM64 executables (essentially GCC toolchain, extracted to app directory (/data/data/%package%/somePath) on the first run) to do some work. Due to Android 10 changes files in /data/data/.. can't have executable permission anymore.
Confirmed workaround
The workaround is to make executables look like shared libraries (libsomething.so) that are extracted by Android to /data/app/%package% dir with android:extractNativeLibs="true" in AndroidManifest.xml and are allowed to have executable permission. Symlinking might be useful to mimic the previous files structure.
The problem
The problem is that all the executables (aka new "shared libs") are packed into android apk with zip compression ratio (as apk is essentially just a zip file) which could be better if it's archived with 7zip for instance and together weight more than 100Mb which is app limitation on Android (for apk files).
The question and the proposal
How can i split the executables into a small part (that goes into /data/app/%package% and a large part (or just existing executable in /data/data/%package%)? The idea is that small executable just "loads and runs" a regular one. The benefit it that regular executable is compressed with 7zip and it makes apk size much smaller due to 7zip used with a better compression ratio.
I've been looking into direction of using of UPX but having no experience with it (note i will have to prepare executable on Mac machine (or Linux with VM or Docker) to run on Android ARM64). Also i've been thinking about creating of 7z sfx but it seems to be tricky (again, it have to be created on x86_64 and run on ARM64). Also I've found some similar QA (which recommends memexec() or fexecve()), but I'm not sure what's the optimal way to go.
Ideally I'd love to have some tiny "universal" ARM64 executable (or be able to compile it from the source code with Android NDK) that just accepts cmd and a regular executable path.
PS. App bundle and dynamic delivery modules as high-level alternatives are undesired for different reasons.
PPS. UPX did not work out of box for Android 10 (seems to be security issue).
Related
i have a separate build-flow that can produce .out files for the MT3620/M4 core using the same gcc-arm compiler.... for reasons beyond the scope of this question, it's not practical for me to migrate this build-flow into cmake....
once i generate the .out file, my thinking was to simply envelop it within a project structure identical to the samples -- with an conforming app_manifest.json file.... from here, i could effectively run just the final step of the cmake build -- which generates the image package....
before i go down this path, is there anything obvious i'm missing here????
As of today you will need to decide to install Azure Sphere SDK Preview for Visual Studio or Azure Sphere SDK Preview for Windows (You cannot install both SDKs on the same PC.)
To develop applications, however, you need to set up your development environment and possibly install additional tools. The Azure Sphere SDK for Windows supports development with the CLI only. If you've installed this version of the SDK, you'll need to install CMake and Ninja on your PC.
If you plan to develop real-time capable applications (RTApps), you might need to install a compiler for the embedded processor and set up hardware to display output from the app.
Both Quickstarts "Build an RTapp on cmd" and "Build an RTApp with Visual Studio" require that you use CMake at some stage and those are the supported methods.
Update: New documentation improvements will be done soon to address the option of using a different build system to cmake and "yes" it should work as you suggest.
I have installed Yocto, and successfully ran host-prepare.sh script. I want to know that, to develop makefile based applications, what to do next, should install toolchain or ADT or kernel & filesystem images? Is there any documentation which has step by step process?
In many cases, one do not need to install Yocto at all, what is needed is just appropriate toolchain along with filesystem image to develop and test simple program with qemu (runqemu - which is emulator - a part of toolchain). These toolchains and filesystem images are available to download and ready to use. Refer 'Using Pre-Built Binaries and QEMU' section in this documentation.
While developing with IBM MobileFirst studio I've found that after building iOS/Android environment and generated native projects, even a blank app (e.g a quite simple Hello World Android app which do not use any native functionality), will take size more than 4Mb which is much larger than a real native exported Android apk file.
So are there any unused resources that can be deleted or other things we can do so that we can lose weight in the final exported apps?
Another detail, the classes.dex file inside the 'blank HelloWorld'apk file seems larger than a common apk file (4Mb size).
Starting MFP 7.0 you can now minify and concatenate mobile environments. This means that in addition to added security, by reducing the amount of files and contents of files, it can help - to some degree - with the filesize of the application.
Read more about application build settings
MFPF 7 supports by default many more hardware architectures. This support is required if you intend on using features such as JSONStore and others. The files adding this support are located at your-app\android\native\libs (arm64-v8a, armabi, armabi-v7a, mips, mips64, x86, x86-64). So if you know you're not using JSONStore for example, see if removing some or all of these files helps you. But also do a regression test in general to make sure that the app continues to work as required. I could be wrong about the scope of these files - which add 3.4MB on disk.
I just downloaded the full 4.0.1_r1 Android Source Code repository according to the official instructions. Can someone help me understand the repository's basic naming scheme?
For example, in the root directory of the repository, what exactly is the "frameworks" directory? How does this differ from the "packages" directory?
I have spend quite a bit of time around the android source code the last few years, so let me take a shot at explaining the different folders in the root. These are roughly (depending a bit on the android version):
bionic
The standard c library used and developed for Android specifically.
bootable
Contains the bootloader (which the device manufacture normally provides) and the recovery application which is execute when the phone is booted into recovery mode.
build
Android has very unique modular build system, which itself is built on top of ordinary make-files. For example in build/target/products you will find all the generic build targets you see when you launch lunch.
cts
Compatibility Test Suite. When a device manufactures wants to get their device certified (and thus get Google Play and other proprietary apps) they need to pass the CTS. The source of CTS is contained in this directory.
dalvik
The dalvik virtual machine. Android uses java for the better part of the framework as well as for all the apps. Because each app runs as its own process under its own uid, in its own virtual machine, the virtual machine have to have a rather small memory footprint, so Android have chosen to use a custom virtual machine for Java called dalvik. The source of dalvik is placed here.
development
I haven't used this repository really, but it seems supporting stuff for developing android apps are placed here.
device
Each device vendor put all the stuff that defines their specific devices here. For example you can provide a devices/{yourname}/products/{yourdevice}.mk defining exactly which apps should be build for your device (as well as a few other things). This adds an entry to the lunch menu called {yourdevice} that you can build.
docs
As far as I understand this is actually the source of http://source.android.com.
external
Almost all of the third party projects that Android pull in and which makes up the base Android Linux OS are located here. They are maintained in their own git repositories, which makes it easy to pull new versions from upstream. You see things like bzip2, dbus, ping, tcpdump, and many other projects here.
frameworks
This is the source of the Android framework. All the stuff that you use when you build an app for Android. I think it is somewhere around 50% Java code and 50% C++ (and sometimes C), which is bound together using jni. When you for example play some audio in an app, you are probably accessing AudioManager. The source of AudioManager as well as all the internal Android source supporting AudioManager is placed under frameworks/base/media. You will find the bulk of the Android SDK implemented somewhere under frameworks/base/.
hardware
Android talks to a set of libraries which then controls the hardware (such as vibrator, lights, proximity sensor, gps, audio, etc.). These libraries are collectively called the HAL (Hardware Abstraction Layer). Some default implementations are contained in the hardware folder, however manufactures implement their own libraries and place them in hardware/{manufcaturename} (or in device/{manufacture}).
libcore
I don't know about this one.
ndk
The native development kit which allows app developers to code some (or all) of their apps as native code (in c and c++ usually). Basically it is a toolchain to crosscompile to the different cpu architectures Android runs on.
out
All Android build artifacts are placed here. So removing the out folder will clean the sources completely. out is divided into different folders, the main ones are host and target where stuff compiled for the host machine (e.g. adb) and for the target device (most of the android system) are separated. There are further subdivisions below, and in general the out folder is quite nicely sorted, so you should just explore it a bit yourself.
packages
These contains all the default apps, providers, inputmethods, and so on, that are built along with Android. The phone app, contacts, calender, calculator, default soft-keyboard, etc, are placed here. They are not 3rd party apps, they are internal apps where many of them are build against non-public android apis. So most of the apps here cannot build against the public Android SDK (e.g. in eclipse), but have to be build as part of the complete Android build process.
prebuilt
Stuff that is distributed along with Android as binaries. The primary thing located here are the crosscompiler(s) for building Android for ARM (and now also x86). They are prebuilt such that you do not have to actually build the crosscompilers yourself. (This could be very time-consuming if you besides Android also had to compile the crosscompilers.)
sdk
All the tools that are part of the Android SDK, such as ddms, the emulator, sdkmanager, etc.
system
The core system processes running on an android device. These are native (c or c++) programs. Mediaservice is an example of such a system service.
This is all from my experience with working with the Android source, I do not have any (other) references. I hope this helps you get an overview of the folder structure.
The mono installation provided at mono-project.com comes packed with several libraries, such as gkt, making the installation quite large (~280MB or so).
Is there any way to provide users with an installation of "just" the mono environment? I am targeting Windows, MacOSX and Linux.
You might be looking for mkbundle which merges your application, the libraries it uses and the Mono runtime into a single executable image. See under "Bundles" in that page.
If you do this though, it may mean that you are distributing LGPL code with all that this implies.
If you are distributing your app for Mac OS X, there is also MonoMacPackager which offers more advanced support for this. I think they have done a bunch of work in the linker to really minimize the amount of Mono that you have to include. It will actually remove unused code from assemblies that you reference.