I want to flash Android O to my hikey960, but the official tutorial is using master branch, which is Android P. I tried using branch android-o-mr1-iot-preview-8 and some others, but all failed to booting. Is there any binary file need to include? Is any tutorial to flash Android O? Thanks!
I’m afraid there are no tutorials for this… mostly because we know it doesn’t work (even when they are built the AOSP 8 branches will not have working graphics acceleration).
Hey, I tried building android O too (see my previous thread), but no luck in terms of getting the Hikey960 to boot up. Consensus from the thread on the forum was also that it was not possible.
I’m a newb, apologies in advance for any inaccuracies.
I see so many threads that end the same way. Someone says that the HiKey 960 is only supported by the master branch without explaining why other branches cannot be built.
For instance, I want to embed the HiKey 960 into a device running Android 8.0 Oreo. 3D graphics performance is important, so we plan to use the Vulkan 1.0 API. The ARM Mali GPU user-space binary drivers support android-8.0.0_r36:
https://developer.arm.com/products/software/mali-drivers/user-space
Why is it impossible to build the android-8.0.0_r36 branch instead of the master branch?
@paul: Probably the reason why nobody elaborates on this is because the reason seems (at least to them) to be obvious… it is because the stable branches of Android do not include the code necessary for the board to function, or at least to function fully.
While there are some files in stable branches pertaining to the Hikey 960, they are not complete and will not work.
To put it another way, the reason why it won’t work with a stable branch of Android 8.0 is the same reason why it won’t work with a stable branch of Android 1.0.
My guess (and it is only a guess) is that you can anticipate support in a stable “P”.
Having said that, there is no technical reason why you could NOT make it work with a stable Android 8.0, but it won’t be a simple matter of running “lunch hikey960-userdebug; make -j17”, but rather you will have to get your hands really dirty.
1 Like
Okay, got it. Thanks!
I’ve been thinking about this.
There might be stable support in P, in fact this has been made more likely by the recent migration of the GPU drivers from tarbal to repo (which means no worries about version skew for the binary blobs). However there are still no guarantees. It will depend entirely on whether there are regressions for hikey960 during the P merge frenzy and how soon P is branched after the merge frenzy.
Anyone who wants known working builds for hikey960 might be better of looking at:
I still don’t fully understand the problem why we cannot build let’s say android-8.0.0_r36. By specifying this tag, the manifest defaults all repository tags to android-8.0.0_r36. There are 5 repositories related to the hikey boards in the manifest, namely arm-trusted-firmware, edk2, OpenPlatformPkg, hikey, and hikey-kernel. These are the same repos which exist in the manifest of the current master and all the repos have a tag named android-8.0.0_r36. So in my head, repo should check out these exact tags, so why can’t we build Android 8.0.0_r36 then?
And I’m sorry, if I’m missing the point, but I just don’t understand the problem. 
Because the part in the code that says this, is not there;
if (hikey960){
do_stuff_needed_by_hikey960();
}
Okay thanks! But at which location(s) does this kind of code live? And why is it not part of the tagged releases?
All over the place.
Because it wasnt written yet.
The status of the reference boards is not usually considered when the branches are made. Instead the decision to branch tends to be based on the status of some production phones instead. If the reference boards were not working at the point the branch is made then the fixes that correct this are typically only made available via the master branch.
All over the place.
Does this mean that backporting the patches to make the hikey board work in any Android 8 version is impossible?
My request comes from the fact that in my field working with an “older” version of android is a quite common request.
It is certainly not impossible… I think I’d be inclined to describe it as fiddly: multiple small problems in an enormous code base.
I think the best approach would be to look at the date Google makes a dump to the master branch and find a known good manifest as soon as after that date. That is now the closest thing to a working old release… from there you need to look for changes in the board support (which is typically reacting to the code dump and fixing things) and apply them to the maintenance branches.
Thanks for the hint, very appreciated, I’ll try to develop from this
I already tried the oldest known good manifest and points to an android 9 release, though
Are you accounting the “more than N-1, less N” behaviour in the master branch (stealing a phrase from @doitright). In otherwords AOSP version number are bumped upwards as soon as they open for development contributing to the next version. Thus an AOSP master branch that reports N consists of the Google’s N-1 work and open source contributions for N (what they do not contain is Google’s private work for N).
It you have an known good manifest shortly after a Google code drop that reports 9 then it is probably closer to 8 than to what 9 will eventually be.
Sorry, I shouldn’t have said “it points to”, but more precisely it builds an image of Android 9
Unfortunately, some of the oldest known-good-manifests are now actually broken due to repository restructuring. HOWEVER, they’re probably pretty decent with respect to hikey/960-specific repositories, so pieces of them can possibly be mixed with release branches.
I don’t think so. The known good manifests are ALL point shots of AOSP MASTER. It SAYS its 9, but its actually more than 8 but less than 9.
If you look at the oldest known good manifest, for example, it is dated February 2018. This is from BEFORE 9 was merged to master – that didn’t happen until around September.
Alright, so there must be a mistake in my build, because once installed into the board, it boots up android 9 
