Hi,
I am very new to Android apps development. Tng E-Wallet, Amonline, Myunifi, shopee kind of have the same theme or maybe the same framework/technologies. Do anyone have info about this? I would like to develop apps with similar interface.

Thanks

Read up on Material Design.

(To avoid opening too many threads at my own, I will post my findings as a reply)

Just started Flutter programming, after loading Demo project, my first step was to learn how to deploy to phone.

Surprisingly, APK can be extracted (in my case, I use 7zip)





From the lib folder, I found libflutter.so and libapp.so, both are ELF Linux binary file! (after inspecting the header)


But it is a bit shocking, to find out app-arm64-v8a-release is 0 byte, means what?

---

I built the release APK according to ABI, according to Flutter documentation:



Has anyone tried to reverse-engineer Android app, or has figured out how to port Android Runtime to x86, or managed to generate minimal binary app
for Android directly (i.e. without using Flutter or can even bypass Android Studio )?

-----

UPDATE:



I built another signed APK from Java (Android Studio) directly, and there is no binary (ELF or whatever). How come?

Android Runtime is Java , so ......

This post has been edited by FlierMate: May 20 2022, 12:16 AM

.dex is the binary. https://source.android.com/devices/tech/dalvik/dex-format

Not Java bytecodes, but equivalent.

There are certain low level stuff where the app utilises native shared libraries (hence the .so files). you can refer to this for further reading: https://developer.android.com/ndk/guides/concepts

libflutter.so from the name seems to be the native shared lib for Flutter, and I suspect libapp.so is the same (never used Flutter before so not sure).

Your other project that does not have the .so files just means that it does not use any native shared libs.

These native shared libs can potentially be the cause of binary file size bloat in Android, as they tend to be fat binaries. If you're to do something like `file <.so filename>`, it'll print out for you the different architectures that the file contains. usually it'll consist of x86, x64, arm32 and arm64

What's normally done to reduce APK size is to split your APKs. you can read up further here: https://developer.android.com/studio/build/...gure-apk-splits

This article starts off by talking about splitting by resolution size, but as you go down further, it goes into splitting by architecture as well. Take note that the architecture split is applicable only to the .so files

However if you utilise app signing by google (only if you're distributing your app on the Playstore), google can now do this splitting for you automatically, where you just upload your single fat APK.

Android Studio the way I see it, it's just a convenient wrapper around gradle, which does the actual build. So yes, if you really want to, you can do without Android Studio as long as you have the Android SDK installed.

Another hint: you can drag and drop the APK file into Android Studio for easier inspection of the APK

This post has been edited by malleus: May 20 2022, 07:44 AM

Thank you for shedding light on this. Android (and Flutter) documentation is ample and huge, I couldn't have known this unless someone point me in the right direction.
There seems like no mystery in either byte-code or Dalvik executable format.


Yes, the shared libs generated by Flutter already accounted for 11MB (uncompressed).
Both projects (Flutter and Java) use basic activity (demo code), but I can notice Java's APK is smaller (2.7MB) than Flutter's APK (5.9MB for armv8a) -- both in release build.

Flutter provides split by ABI, I think that would split its internal .so by architecture as well?

Yes, I will notice the Analyze APK function in Android Studio. Too new to Android stuff, I really enjoyed reading your comment. Thank you.

Someone wrote a "Hello, world" example for Dalvik executable (to be compiled by FASMg)

https://board.flatassembler.net/topic.php?p=222849#222849

Although his example runs the code through Dalvik VM (Android Runtime?) but the "HELLO" string is displayed on PC's terminal window, not on Android device.



Something to work on!

The author of an ARM assembler confirmed, that Android apps are not using assembly code, all are written in High Level Language (HLL) like what I have discovered - Dalvik bytecode (thanks angch).
So people are frustrated because they were expecting to write ARM assembly code for Android.

Android phone have arm, arm64, i386 and x86_64 CPU.

if most of the app can run on all devices,
it shouldn't be machine code.

Only those people who develop hardware driver,
or android sdk is not enough for them (e.g. Unity or Unreal Engine),
they use c/c++.

Most react native .apks have native libjsc for the all supported platforms (arm, x86_64, etc) bundled in lib/*. No one writes specific Android apps directly in ARM. That's silly.

Anyway, for funsies, note that jadx decompiles .dex (well, .apk) into Java.

https://github.com/skylot/jadx

If the os not allow (decode the file differently),
there is no way to write the app by using native machine code (or asm)

the code may be run under a sandbox environment, which might not understand machine code.