JBQ
was about to test this, but got an error thrown right after make:
build/core/base_rules.mk:78: *** Module name: uix
build/core/base_rules.mk:79: *** Makefile location:
sdk/layoutopt/libs/uix/src
build/core/base_rules.mk:80: *
build/core/base_rules.mk:81: * Each module must use a LOCAL_MODULE_TAGS
in its
build/core/base_rules.mk:82: * Android.mk. Possible tags declared by a
module:
[...]
If I add the 'LOCAL_MODULE_TAGS := optional' into the Android.mk for
this module, then it fails on the next:
build/core/base_rules.mk:78: *** Module name: layoutopt
build/core/base_rules.mk:79: *** Makefile location: sdk/layoutopt/app/etc
[...]
build/core/base_rules.mk:78: *** Module name: layoutopt
build/core/base_rules.mk:79: *** Makefile location: sdk/layoutopt/app/src
And so on.... so I guess I am doing something wrong. Any hint would be
appreciated.
Cheers,
Pau Oliva
make: *** No rule to make target
`prebuilts/qemu-kernel/arm/LINUX_KERNEL_COPYING', needed by
`out/target/product/maguro/obj/NOTICE_FILES/src/kernel.txt'. Stop.
JBQ
> --
> 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
JBQ
build/tools/releasetools/ota_from_target_files -w -i ~/aosp-ota-exp/stub-yakju-target_files-icl53f.zip -k build/target/product/security/testkey out/dist/full_maguro-target_files-eng.*.zip ~/aosp-ota-exp/cache/aosp_update.zip
make_ext4fs -s -l 209715200 -a cache ~/aosp-ota-exp/cache.img ~/aosp-ota-exp/cache
ERROR: failed to unzip input target-files "/home/jfdionne/aosp-ota-exp/stub-yakju-target_files-icl53f.zip"
build/tools/releasetools/ota_from_target_files -w -i ~/aosp-ota-exp/stub-yakju-target_files-icl53f.zip -k build/target/product/security/testkey out/dist/full_maguro-target_files-eng.*.zip ~/aosp-ota-exp/cache/aosp_update.zip
unzipping target target-files...
using device-specific extensions in device/samsung/tuna
unzipping source target-files...
unzip: cannot find or open /home/jfdionne/aosp-ota-exp/stub-yakju-target_files-icl53f.zip, /home/jfdionne/aosp-ota-exp/stub-yakju-target_files-icl53f.zip.zip or /home/jfdionne/aosp-ota-exp/stub-yakju-target_files-icl53f.zip.ZIP.
http://pof.eslack.org/tmp/gnex.jpg
just to make sure there is no mistake on my side, this is the content of
the generated aosp_update.zip file:
http://pof.eslack.org/tmp/aosp_update_contents.txt
Let me know if there's anything else I can try.
Cheers,
Pau Oliva
JBQ
try to rerun these
My guess is that you forgot to extract the proprietary binaries from
imgtec (and maybe samsung) before doing your build, and the scripts I
posted don't re-use those binaries from the existing system (they
wouldn't work anyway, the 4.0.2 graphics libraries don't work on the
4.0.3 kernel).
JBQ
now I'm stuck at make_ext4fs: command not found
Not sure where to get that command
source build/envsetup.sh
# ...
lunch full_maguro-userdebug
# ...
make make_ext4fs
# ...
which make_ext4fs
# .../out/host/linux-x86/bin/make_ext4fs
JBQ
Now that those files are in place, I flashed again and it boots nicely
on full AOSP... camera working perfect after following your steps, thank
you :)
http://pof.eslack.org/archives/images/maguro-full-aosp.jpg
This gives me 2 conclusions:
-It's possible to make this work.
-It really needs to be automated a lot more before it can be unleashed
on the general public, since even with a lot of care it's easy to miss
a step or two.
JBQ
Do you see something that might not work by using this method? If there
are no obvious stoppers I'll give it a try later today.
Cheers,
Pau Oliva
As for preserving apks, here are some issues that come to mind:
-If any apk needs to be signed with the platform key, you'll be out of
luck, since that's not going to match the key you use for the AOSP
build.
-You'll need to preserve the odex files. Since those aren't fully
portable, that limits the types of changes you can do to dalvik.
-You'll probably need to trim the AOSP build a bit. E.g. Provision
isn't used in retail builds as there's a full-featured equivalent.
-You'll have to make choices for some of the apps: e.g. the AOSP
LatinIME doesn't have all the features of the retail one, so you could
end up deciding to keep the retail one even though there's an
Open-Source variant.
Finally, if any of those apps rely on proprietary overlays that'd be
applied to e.g. the framework, you could have mismatches with unknown
consequences. I don't expect that'd be the case, but you never know.
JBQ
[...]
> As for preserving apks, here are some issues that come to mind:
>
> -If any apk needs to be signed with the platform key, you'll be out
> of luck, since that's not going to match the key you use for the AOSP
> build.
>
> -You'll need to preserve the odex files. Since those aren't fully
> portable, that limits the types of changes you can do to dalvik.
Will this work in practice? Doesn't an odex file require that all
jar files it uses are identical to what they were in the environment in
which the odex file was created? In other words, touch framework.jar and
all odex files will be void.
[...]
--
Magnus B�ck
ba...@swipnet.se
For practical purposes, that means that we can't replace the framework
(or any other libraries) and continue using apks that had been
pre-dex-opt'ed on a different build.
JBQ
> Magnus Bäck
> ba...@swipnet.se
Hi Leon,
Are you in the root of the android sources? Have you synced? Does
the build directory exist?
FYI, this command is more or less the same as doing:
cd build
git pull https://android.googlesource.com/platform/build refs/changes/64/31464/1
and it sounds like it's having trouble with the "cd build" part.
~cco3