Re: [android-building] AOSP libselinux build error for android-q-preview-1
Google pushed a tag to AOSP named "android-q-preview-1" a few days ago but it is unclear what exactly makes it "Q" since the API level didn't change and it appears to be missing new APIs like Activity#onTopResumedActivityChanged() Would be nice if someone could explain what exactly the "android-q-preview-1" tag is. I guess Google won't actually be releasing the source code for Q until after they go through several preview releases? It appears that is what they did last time with Pie. Jacob On Thursday, March 14, 2019 at 8:29:47 AM UTC-7, shahul hameed wrote: > > Hi Jacob, > > Is Android Q source available? can you share me link to download source. > > Regards, > SkShahul. > > On Thu, Mar 14, 2019, 11:31 AM Jacob Abrams > wrote: > >> Getting the following error when trying to build Q preview aosp generic >> aosp_arm: >> >> >> PLATFORM_VERSION_CODENAME=Q >> PLATFORM_VERSION=Q >> TARGET_PRODUCT=aosp_arm >> TARGET_BUILD_VARIANT=eng >> TARGET_BUILD_TYPE=release >> TARGET_ARCH=arm >> TARGET_ARCH_VARIANT=armv7-a-neon >> TARGET_CPU_VARIANT=generic >> HOST_ARCH=x86_64 >> HOST_2ND_ARCH=x86 >> HOST_OS=linux >> HOST_OS_EXTRA=Linux-4.15.0-45-generic-x86_64-Ubuntu-16.04.6-LTS >> HOST_CROSS_OS=windows >> HOST_CROSS_ARCH=x86 >> HOST_CROSS_2ND_ARCH=x86_64 >> HOST_BUILD_TYPE=release >> BUILD_ID=PI >> OUT_DIR=out >> >> [100% 134/134] out/soong/.bootstrap/bin/soong_build out/soong/build.ninja >> FAILED: out/soong/build.ninja >> out/soong/.bootstrap/bin/soong_build -t -l >> out/.module_paths/Android.bp.list -b out/soong -n out -d >> out/soong/build.ninja.d -globFile out/soong/.bootstrap/build-globs.ninja -o >> out/soong/build.ninja Android.bp >> error: frameworks/native/libs/gui/Android.bp:20:1: module "libgui" >> variant "android_arm_armv7-a-neon_core_shared_asan": links a library >> "libselinux" which is not LL-NDK, VNDK-SP, or explicitly marked as >> 'double_loadable:true'. (dependency: libgui -> libbufferhubqueue -> >> libpdx_default_transport -> libselinux) >> >> I went to external/selinux/libselinux/Android.bp and added >> "double_loadable: true" to that particular module and the build is >> continuing now. Not sure what effect that has, but likely needs a fix? >> >> Best, >> Jacob >> >> -- >> -- >> You received this message because you are subscribed to the "Android >> Building" mailing list. >> To post to this group, send email to android-...@googlegroups.com >> >> To unsubscribe from this group, send email to >> android-buildi...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/android-building?hl=en >> >> --- >> You received this message because you are subscribed to the Google Groups >> "Android Building" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to android-buildi...@googlegroups.com . >> For more options, visit https://groups.google.com/d/optout. >> > -- -- You received this message because you are subscribed to the "Android Building" mailing list. To post to this group, send email to android-building@googlegroups.com To unsubscribe from this group, send email to android-building+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-building?hl=en --- You received this message because you are subscribed to the Google Groups "Android Building" group. To unsubscribe from this group and stop receiving emails from it, send an email to android-building+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[android-building] AOSP libselinux build error for android-q-preview-1
Getting the following error when trying to build Q preview aosp generic aosp_arm: PLATFORM_VERSION_CODENAME=Q PLATFORM_VERSION=Q TARGET_PRODUCT=aosp_arm TARGET_BUILD_VARIANT=eng TARGET_BUILD_TYPE=release TARGET_ARCH=arm TARGET_ARCH_VARIANT=armv7-a-neon TARGET_CPU_VARIANT=generic HOST_ARCH=x86_64 HOST_2ND_ARCH=x86 HOST_OS=linux HOST_OS_EXTRA=Linux-4.15.0-45-generic-x86_64-Ubuntu-16.04.6-LTS HOST_CROSS_OS=windows HOST_CROSS_ARCH=x86 HOST_CROSS_2ND_ARCH=x86_64 HOST_BUILD_TYPE=release BUILD_ID=PI OUT_DIR=out [100% 134/134] out/soong/.bootstrap/bin/soong_build out/soong/build.ninja FAILED: out/soong/build.ninja out/soong/.bootstrap/bin/soong_build -t -l out/.module_paths/Android.bp.list -b out/soong -n out -d out/soong/build.ninja.d -globFile out/soong/.bootstrap/build-globs.ninja -o out/soong/build.ninja Android.bp error: frameworks/native/libs/gui/Android.bp:20:1: module "libgui" variant "android_arm_armv7-a-neon_core_shared_asan": links a library "libselinux" which is not LL-NDK, VNDK-SP, or explicitly marked as 'double_loadable:true'. (dependency: libgui -> libbufferhubqueue -> libpdx_default_transport -> libselinux) I went to external/selinux/libselinux/Android.bp and added "double_loadable: true" to that particular module and the build is continuing now. Not sure what effect that has, but likely needs a fix? Best, Jacob -- -- You received this message because you are subscribed to the "Android Building" mailing list. To post to this group, send email to android-building@googlegroups.com To unsubscribe from this group, send email to android-building+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-building?hl=en --- You received this message because you are subscribed to the Google Groups "Android Building" group. To unsubscribe from this group and stop receiving emails from it, send an email to android-building+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[android-building] Has anyone built AOSP with Ubuntu 18.04?
Curious if anyone out there tried to build android on Ubuntu 18.04? If so any notes you can provide on the experience? Thanks. -- -- You received this message because you are subscribed to the "Android Building" mailing list. To post to this group, send email to android-building@googlegroups.com To unsubscribe from this group, send email to android-building+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-building?hl=en --- You received this message because you are subscribed to the Google Groups "Android Building" group. To unsubscribe from this group and stop receiving emails from it, send an email to android-building+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[android-building] Re: Oreo: building modules with mm is incredibly slow compared to nougat
It's not a Google issue. If you checkout pure AOSP 8.1 and build it you will see performance of mm is fast. It's a problem with Qualcomm modifications to the build system. Search your build directory for the string "Fix Later" and run git blame. Jacob On Wednesday, April 4, 2018 at 7:43:06 AM UTC-7, Quang Lam wrote: > > The strungle is real. When I use mmm command on Android 8.1, I spend a lot > of time here: > > [2/2] bootstrap out/soong/.minibootstrap/build.ninja.in > [1/1] out/soong/.bootstrap/bin/minibp out/soong/.bootstrap/build.ninja > [1/1] out/soong/.bootstrap/bin/soong_build out/soong/build.ninja > > in comparation with Android 7.1. > > On Wednesday, January 10, 2018 at 10:41:56 PM UTC+7, Jeffrey Blattman > wrote: >> >> Here are some numbers. Same code, same makefile. This is from a >> non-clean, previously built module in both cases. So there should be >> nothing to do at all. >> >> *On Nougat* >> >> SetupWizard $ time mm >> >> PLATFORM_VERSION_CODENAME=REL >> ... cut ... >> >> make: Entering directory `...' >> Running kati to generate build-d09ceb6bedfc4dba54e0e2e097f22474.ninja... >> No need to regenerate ninja file >> Starting build with ninja >> ninja: Entering directory `.' >> [100% 1/1] Ensure Jack server is installed and started >> Jack server already installed in "/home/jeff/.jack-server" >> Server is already running >> Bad request, see Jack server log >> make: Leaving directory `...' >> >> make completed successfully (2 seconds) >> >> >> *real 0m2.146s* >> user 0m0.700s >> sys 0m0.268s >> >> >> *On Oreo* >> >> SetupWizard $ time mm >> make: Entering directory `...' >> >> PLATFORM_VERSION_CODENAME=REL >> ... cut ... >> >> [2/2] bootstrap out/soong/.minibootstrap/build.ninja.in >> [1/1] out/soong/.bootstrap/bin/minibp out/soong/.bootstrap/build.ninja >> [1/1] out/soong/.bootstrap/bin/soong_build out/soong/build.ninja >> Clang SA is not enabled >> No need to regenerate ninja file >> [100% 1/1] out/soong/.bootstrap/bin/soong_build out/soong/build.ninja >> Clang SA is not enabled >> [100% 1/1] Ensuring Jack server is installed and started >> Jack server already installed in "/home/jeff/.jack-server" >> Server is already running >> make: Leaving directory `...' >> >> make completed successfully (23 seconds) >> >> >> *real 0m22.377s* >> user 1m4.048s >> sys 0m9.104s >> >> So on Oreo, it takes 22 seconds to perform a build that does nothing? >> >> ??? >> Thanks. >> >> -- -- You received this message because you are subscribed to the "Android Building" mailing list. To post to this group, send email to android-building@googlegroups.com To unsubscribe from this group, send email to android-building+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-building?hl=en --- You received this message because you are subscribed to the Google Groups "Android Building" group. To unsubscribe from this group and stop receiving emails from it, send an email to android-building+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[android-building] Re: Soong confusion
Hello, I would like to voice protest over the AOSP build system switch from Make to Soong. Make is not a perfect tool but it is well documented and extremely stable. The introduction of ninja into AOSP was seamless and acceptable. However, migrating away from Make to a totally new tool with zero history is a serious set back. Why not instead choose Bazel, Tup, Gradle, Buck or simply stick with what works? I read the following statements from one of the developers of Soong build: > One of our goals for build health is to reduce the number of different > ways we build modules. Adding too many build flags makes it harder to > tell if a change will break the build, and hard to run tests. We > would much rather compiling everything the same on all devices, and > then determine which parts to use at runtime. It is unclear what is meant by "reduce the number of different ways we build modules.", nor is it clear what is meant by "We would much rather compiling everything the same on all devices". This seems to conflict with the example of LLVM where the build basically consists of completely custom go code: https://android.googlesource.com/platform/external/llvm/+/master/soong/llvm.go Clearly this custom go code does not reduce the number of different ways modules are built. I assume this is an attempt to improve build performance yet again, but it ends up wasting thousands of engineering hours across the globe. Engineers must figure out a new system that likely contains numerous bugs and could possibly be destined for the dustbin if it is not maintained properly or turns out to be inferior. If the goal is to improve build performance perhaps Google engineers could explore an under-the-hood contribution to Make itself? Android is mature; it deserves a mature build system. Jacob Abrams -- -- You received this message because you are subscribed to the "Android Building" mailing list. To post to this group, send email to android-building@googlegroups.com To unsubscribe from this group, send email to android-building+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-building?hl=en --- You received this message because you are subscribed to the Google Groups "Android Building" group. To unsubscribe from this group and stop receiving emails from it, send an email to android-building+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [android-building] Re: How to deploy module with odex?
I'm working on a Marshmallow system and having more problems than ever.
*LOCAL_DEX_PREOPT
*is just the first step. Then I ran into linux permission trouble and
SELinux...
When pushing the system APK I get errors such as:
02-01 20:58:26.302 E/dex2oat ( 3045): Failed to create oat file:
/data/dalvik-cache/arm64/system@priv-app@x...@xyz.apk@classes.dex:
Permission denied
[ 1614.216323] type=1400 audit(686361.299:48): avc: denied { write } for
pid=2640 comm="oid.xyz" name="arm64" dev="dm-0" ino=360453
scontext=u:r:system_app:s0 tcontext=u:object_r:dalvikcache_data_file:s0
tclass=dir permissive=0
To fix this stuff I had to modify *app_main.cpp:*
+// For engineers, needed to allow pushing locally built APKs
+int dalvikCacheDirAid = AID_ROOT;
+char prop[PROP_VALUE_MAX];
+if (property_get("ro.build.type", prop, NULL) != 0) {
+if (strcmp("eng", prop) == 0) {
+dalvikCacheDirAid = AID_SYSTEM;
+}
+}
// We always perform these steps because the directory might
// already exist, with wider permissions and a different owner
// than we'd like.
-result = chown(dalvikCacheDir, AID_ROOT, AID_ROOT);
+result = chown(dalvikCacheDir, dalvikCacheDirAid, dalvikCacheDirAid);
Then I had to make changes to SELinux...
*system_app.te:*
+userdebug_or_eng(`
+ allow system_app dalvikcache_data_file:file rw_file_perms;
+ allow system_app dalvikcache_data_file:dir rw_dir_perms;
+')
*domain.te:*
neverallow {
domain
-init # TODO: limit init to relabelfrom for files
-zygote
-installd
-dex2oat
+ userdebug_or_eng(`
+-system_app
+ ')
} dalvikcache_data_file:file no_w_file_perms;
neverallow {
domain
-init
-installd
-dex2oat
-zygote
+ userdebug_or_eng(`
+-system_app
+ ')
} dalvikcache_data_file:dir no_w_dir_perms;
Pretty ugly, maybe there is an easier way?
On Monday, February 1, 2016 at 11:09:40 PM UTC-8, liuyafei wrote:
>
> Modify BoardConfig.mk works for me, the BoardConfig.mk override the
> *LOCAL_DEX_PREOPT
> *in my case
>
> On 2016年02月01日 22:47, Arne-Christian Blystad wrote:
>
> Do you have WITH_DEXPREOPT enabled in your BoardConfig.mk? Best solution I
> found was to just turn that off for development builds. For release builds
> (built on our build server) we have it turned on.
>
> You could also try deleting the file from /data/dalvik-cache/arm/your
> module (it has a longer name, for example:
> sys...@priv-app@sh...@shell.apk@classes.dex ).
>
> On Thursday, 28 January 2016 00:33:37 UTC+1, yf...@mobvoi.com wrote:
>>
>> I'm writing some modules based on aosp 5.1, every time I use `mmm
>> vender/PATH_OF_MY_APP`, it will create a odex file. funny thing is that
>> even I claimed *LOCAL_DEX_PREOPT := false* in my Android.mk file, the
>> odex file will still be generated. If I use `adb install -r myapp.apk`, it
>> will show *Failure [INSTALL_FAILED_DEXOPT]*, if I use `adb push`, no
>> matter push single apk or apk with odex, no matter reboot or not, the
>> application on the board seems no change. The only way to make things works
>> for me is use `make` and burn the image to the board. Since every one says
>> that *LOCAL_DEX_PREOPT := false *will solve this problem, why my
>> Android.mk still generate odex? And what is the usual way to deploy a
>> module?
>>
> --
> --
> You received this message because you are subscribed to the "Android
> Building" mailing list.
> To post to this group, send email to android-...@googlegroups.com
>
> To unsubscribe from this group, send email to
> android-buildi...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/android-building?hl=en
>
> ---
> You received this message because you are subscribed to the Google Groups
> "Android Building" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to android-buildi...@googlegroups.com .
> For more options, visit https://groups.google.com/d/optout.
>
>
>
--
--
You received this message because you are subscribed to the "Android Building"
mailing list.
To post to this group, send email to android-building@googlegroups.com
To unsubscribe from this group, send email to
android-building+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-building?hl=en
---
You received this message because you are subscribed to the Google Groups
"Android Building" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to android-building+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
