So I have downloaded the master AOSP i.e Lollipop. I want to build it for Xiaomi Redmi 1s. The device specific sources are available on github on this link: https://github.com/armani-dev
So what modifications I have to make to successfully build the ROM.
Use other AOSP device trees as reference.
Change any mentions of CM to AOSP.
You'll probably have issues with the overlay folder, so I'd say you're best off deleting it for now.
And just saying, if you don't have any experience with porting custom ROMs and modifying makefiles, then you'll have big trouble getting AOSP Lollipop up and running.
You're better off waiting a month or so until Cyanogenmod Lollipop code is stable enough to be built. You'll have a much easier time building.
Related
I read somewhere that Flutter compiles its code to ARM binaries. These ARM binaries can be understood by both ios and android and thats how flutter achieves cross-platform. If so where can we see ARM binaries? Are APK and ARM binary the same?
Can someone share some more details on it?
Here's an explanation about the comparison of dart's compiled binaries and android's apk. The page also has explanation about iOS platform compilation with Flutter. This paragraph also talks about how the Flutter VM is used, just in case you wanted to know about the JIT compiler. https://docs.flutter.dev/resources/faq#run-android
The engine’s C and C++ code are compiled with Android’s NDK. The Dart
code (both the SDK’s and yours) are ahead-of-time (AOT) compiled into
native, ARM, and x86 libraries. Those libraries are included in a
“runner” Android project, and the whole thing is built into an .apk.
When launched, the app loads the Flutter library. Any rendering,
input, or event handling, and so on, is delegated to the compiled
Flutter and app code. This is similar to the way many game engines
work.
During debug mode, Flutter uses a virtual machine (VM) to run its code
in order to enable stateful hot reload, a feature that lets you make
changes to your running code without recompilation. You’ll see a
“debug” banner in the top right-hand corner of your app when running
in this mode, to remind you that performance is not characteristic of
the finished release app.
I started learning AR 1 week ago. I started building marker-based AR projects using unity and vuforia. But after installing the project apk in my oneplus nord, app is just showing black screen after asking for camera permission.
I searched about this online and found that it may be occurring because of vulkan, so I deleted it! But the same problem is still there!
I have spent so much time searching for a fix to this issue, it would be of great if someone will help regarding this!
This is probably related to Google removing ARCore support for 32-bit apps on 64-bit devices. You should switch the scripting backend in the project settings from 'Mono' to 'IL2CPP' and target both the ARMv7 and ARM64 architectures.
When building Android,
lunch
possible images are:
...
5. aosp_x86-eng
6. aosp_x86_64-eng
...
16. mini_emulator_x86-userdebug
17. mini_emulator_x86_64-userdebug
...
What is exactly mini_emulator? What is the difference between mini_emulator and aosp_x86?
You can find the configurations here:
build/make/target/product/aosp_x86.mk
build/make/target/product/aosp_x86_64.mk
device/generic/mini-emulator-x86/mini_emulator_x86.mk
device/generic/mini-emulator-x86/mini_emulator_x86_64.mk
The names of these configurations mean:
aosp means a full-featured Android. Sometimes also refered to as Generic System Images.
mini means a reduced Android.
emulator means that this Android is meant to be run in the qemu-emulator.
x86 and x86_64 describe the architecture.
eng means
Development configuration with additional debugging tools
userdebug means
Like user but with root access and debug capability; preferred for debugging
I have a Unity project that I'm switching from APKs to AABs (app bundles). Previously, when I was building it as an APK, the Google Play Console told me the APK was 64-bit compliant.
Now that I'm building an aab, I'm getting the warning:
This release is not compliant with the Google Play 64-bit requirement.
The following APKs or App Bundles are available to 64-bit devices, but
they only have 32-bit native code
I have both ARM7 and ARM64 architectures set.
I am excluding x86.
When I open the .aab in an archive viewer, the lib folder has all of
the .so's for both arm64-v8a and armabi-v7a.
I'm using IL2CPP, .NET 4.x
I'm using Unity 2018.3.7f1
My ndk version is 16b
My
Android Studio is up to 3.4.2 and gradle is 3.2
A lot of similar threads here talk about following the "Learn more" links, which I've done. I had already done all of the work to get my app 64-bit compliant before switching to app bundles.
Other threads talk about Android Studio solutions, which I can't use because my automated build process involves building with Unity from command line, so it has to be Unity configurations or bust.
My expectation was the app bundles were supposed to be the hot new way to let Google build better APKs for you, but it seems like it's getting confused on whether or not aabs are actually 64-bit compliant, which seems to defeat the whole purpose.
Is this a Unity problem, does Google have an error in their system with regards to app bundles, or is there some other step I'm missing?
For those who have this problem since yesterday (August 19, 2019):
In Player Settings > Other Settings you must now uncheck the x86 box (It is for the 32-bit Intel architecture).
You will now only have the following warning:
The device types on which your application can be installed will be more restricted.
But, in my case, it drops from 12392 devices to 12385 devices.
Here is the opinion of a Unity member on the issue:
x86 is used by less than 0.4% of all Android devices, so it shouldn't have any real impact.
x86 target will be removed completely in Unity 2019.3.
It looks that there was a bug in the Play Console where this message was displayed even when the AAB was compliant. This should have been fixed last Friday afternoon.
Try again now.
I'm running into this basic issue while integrating the AppWarp Unity SDK (no version is specified, downloaded on 10 of March) with Unity 4.3.4 Android player.
The AppWarpVikingMobile sample fails with the same error.
"telnet appwarp.shephertz.com 12346" does connect to the server. Wireshark shows no packets (running with a filter "host appwarp.shephertz.com").
There is a similar issue asked here on February, but it is unresolved still.
Seems that it's SDK import/compatibility issue.
Any ideas?
When running in the player you have to use the AppWarpUnity.dll asset. Its only when building the apk to run on a physical device you need to build with AppWarpUnityMobile.dll asset (and NOT AppWarpUnity.dll) along with the native plugins provided.
It can be a bit confusing because Unity has different restrictions on different versions (Pro and Free) for different platforms with regards to plugins and sockets. AppWarp's goal is to give developers a way to use it with or without the Unity Pro on all platforms.
The interface exposed by the assets is the same so your application code need not change.