Anyone tried Anbox-4-arm64 yet?
#11
I have had build success for main anbox by avoiding desktop environment, built in tty. I have not gotten farther than this. Not sure why, doing things in TTY on pbp seems to succeed more often for me, like the keyboard firmware updater.

Other than this, followed the raspberry pi tutorial without 32 bit options, specified cores for build because it errored otherwise. "make -j 4" (i only didn't use 6 because i was being superstitious at this point)

yeah so success, at least with build, will report back on actual usage

edit:
reporting back

i don't have any idea what to do to actually use anbox, i have never used it before LOL

the rpi tutorial after install step says "This downloads ~ 40GB of sources and uses ~ 100GB of disk space. You need a powerful desktop for this step. It will take hours."

wtf, this has got to be wrong

ITS INSTALLED THOUGH

 

  [Image: kLpyCqn.png]


ill look into trying to use it later, i have a feeling there are a lot more hurdles to overcome here
  Reply
#12
Awesome! What OS is this on?
  Reply
#13
manjaro!
  Reply
#14
(01-17-2020, 09:55 PM)aaspectre Wrote: manjaro!

I can't wait to try replicating this! @PakoSt  you seeing this?
  Reply
#15
Nice! @aaspectre , can you start a session with anbox?

Device: Pinebook Pro 128GB No:246 / MainOS: Manjaro ARM
Godot and Flutter - creating something can be fun with the right tools!
  Reply
#16
(01-18-2020, 07:34 AM).PakoSt Wrote: Nice! @aaspectre , can you start a session with anbox?

Still downloading the resources to build Android itself, though it seems promising since there is a "anbox_arm64-userdebug" build target suggested right in the anbox docs, and every step of the process of making that into something that works with anbox is also documented. I'm optimistic that the process of getting everything into place will go smoothly at least.

I initially tried to run a session from the existing PBP android image made for booting from, which failed. I didn't really expect that to work anyway.

Seems to be a lot of time and storage to actually build the Android image, which I was trying to avoid, but I guess I can't. I will report back as soon as I get everything needed into place to actually try and start a session.
  Reply
#17
You can use this android image, too, you just have to rename is android.img when you put it into /var/lib/anbox

https://build.anbox.io/android-images/20..._arm64.img

I just tried finishing building my local copy, and it failed in tty at the same spot Sad maybe I need to start over, fresh.

Another potentially helpful resource for anyone that gets anbox running: https://github.com/geeks-r-us/anbox-playstore-installer
  Reply
#18
i actually found that just before you posted that, the container and session starts, but the window is black. it appears to be functioning underneath it all, though.

classic mali moment, both on fbturbo and panfrost have the same result. building swiftshader right now to try software rendering

also all i did for the build was firstly using the rebornos modules as you said and then, literally followed the raspi tutorial just skipping the "Replace uint64_t with uint32_t in src/anbox/input/device.cpp, struct CompatEvent." step. i'd just do a new clone and retry, it doesn't take that long to build if you use all 6 cores anyhow! (make -j 6)

welp, swiftshader build failed. I'm at all loss until i regain the patience to get swiftshader built. Everything does seem to be working though, i'm able to get an adb shell into the running session, and all seems normal, literally no errors besides network not being connected. i am fairly confident this is down to mali being mali.
  Reply
#19
I think sticking with-j4 is probably better. I used 6 a bit ago, after prefixing the filename of cmake/findgmock (it was giving me a problem that others resolved by removing it in cmakelists.txt) and my PBP is frozen at 46% of the build. I'm going to check back on it later, as it probably just needs lots of time now to do its thing.

I'm a dummy, I thought the last command I issues was make -j6, instead it was make -j12 from another project. Ooops. Running again with 6 after that build 'm messing this up, even though I am getting more progress than before (92 vs 91%) I still seem to keep having issues with test.

Would you be open to generating a pkgbuild of your successful build? Also, did you install Reborn's Anbox-manager by chance? It's supposed to make using anbox a bit easier. It also has nifty little bit that shows a verification of the various parts start/running correctly.
  Reply
#20
i never really learnd 2 pkgbuild for anything but binaries despite being an arch user and even aur maintainer of some packages for years now tbh, embarrassing truth, though i'm sure i could learn in short order

have you run make with -k? i may have done that... but i may just be making stuff up because i'm second guessing myself. i will look into reproducing the build tomorrow, so i can figure out exactly what went right. it may be worth first making a copy of the repo dir and running make with -i, which makes it just pretend it's successful and keep going, this is def not good practice, and may (probably will) break things, but it also may work just fine.

otherwise, i'm really stuck on the graphics issue, swiftshader really does not want to build for some reason and that's what anbox uses to do software rendering, which is important because i suspect the graphics issue to be related to the not 100% functional status of mali t860 rn. there is also a (undocumented afaik) --gles-driver= arg for anbox session that seems to literally do nothing no matter what i put, but that seems like a promising lead.

i will also try the anbox manager tomorrow as well, provided it's not architecturally dependent on x86
  Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  Compile of Anbox fails because kernel function kallsyms_lookup_name() is unexported Tsvi Bar-David 6 8,751 06-30-2020, 06:41 AM
Last Post: tophneal

Forum Jump:


Users browsing this thread: 1 Guest(s)