January 05, 2016
Huawei Watch rooted with custom OS (since it seemed easiest way to run an executable via adb shell, and Terminal Emulator is not so usable on that size screen).

Android 5.1.1 Wear 1.3.0
Qualcomm MSM8926 Snapdragon 400
Quad-core 1.2 GHz Cortex-A7

All tests passed (command line).  no end-point mapper since Wear doesn't give you tcp access even though the watch has wifi.


0.001s PASS release32 core.atomic
0.174s PASS release32 core.bitop
0.000s PASS release32 core.checkedint
0.014s PASS release32 core.memory
0.000s PASS release32 core.exception
0.000s PASS release32 core.math
0.010s PASS release32 core.demangle
1.566s PASS release32 core.time
0.955s PASS release32 core.thread
0.000s PASS release32 core.internal.convert
0.000s PASS release32 core.internal.hash
0.000s PASS release32 core.sync.config
0.019s PASS release32 core.sync.mutex
0.039s PASS release32 core.sync.condition
0.009s PASS release32 core.sync.barrier
0.044s PASS release32 core.sync.rwmutex
0.000s PASS release32 core.sys.posix.sys.select
0.006s PASS release32 object
0.000s PASS release32 rt.aaA
0.001s PASS release32 rt.arraybyte
0.000s PASS release32 rt.arrayassign
0.000s PASS release32 rt.cover
0.000s PASS release32 rt.arraycast
0.000s PASS release32 rt.minfo
0.006s PASS release32 rt.arraydouble
0.000s PASS release32 rt.qsort
0.000s PASS release32 rt.typeinfo.ti_Aint
0.000s PASS release32 rt.adi
0.068s PASS release32 rt.lifetime
0.000s PASS release32 rt.monitor_
0.000s PASS release32 rt.arrayreal
0.003s PASS release32 rt.arrayfloat
0.000s PASS release32 rt.util.string
0.000s PASS release32 rt.util.utf
0.000s PASS release32 rt.util.hash
0.589s PASS release32 rt.util.container.treap
0.001s PASS release32 rt.util.container.hashtab
0.000s PASS release32 rt.util.container.array
0.002s PASS release32 rt.util.typeinfo
0.002s PASS release32 rt.arrayshort
0.000s PASS release32 rt.aApply
0.000s PASS release32 rt.switch_
0.009s PASS release32 rt.arrayint
0.000s PASS release32 rt.aApplyR
0.000s PASS release32 gc.config
0.000s PASS release32 gc.gc
0.000s PASS release32 gc.bits
0.000s PASS release32 gc.pooltable
0.000s PASS release32 std.typetuple
0.033s PASS release32 std.format
0.167s PASS release32 std.conv
 47.344s PASS release32 std.random
0.617s PASS release32 std.uni
0.012s PASS release32 std.encoding
0.011s PASS release32 std.zip
0.013s PASS release32 std.variant
0.002s PASS release32 std.mmfile
0.032s PASS release32 std.path
1.338s PASS release32 std.process
38.710s PASS release32 std.datetime
0.002s PASS release32 std.cstream
0.004s PASS release32 std.meta
No service for epmap.
7.741s PASS release32 std.socket
0.000s PASS release32 std.signals
0.000s PASS release32 std.typelist
0.000s PASS release32 std.outbuffer
0.105s PASS release32 std.stdio
0.008s PASS release32 std.csv
0.006s PASS release32 std.xml
0.000s PASS release32 std.mathspecial
0.013s PASS release32 std.exception
0.008s PASS release32 std.math
0.059s PASS release32 std.uuid
0.349s PASS release32 std.string
0.005s PASS release32 std.traits
0.008s PASS release32 std.ascii
0.000s PASS release32 std.complex
0.007s PASS release32 std.functional
0.019s PASS release32 std.typecons
0.009s PASS release32 std.getopt
0.032s PASS release32 std.utf
5.807s PASS release32 std.uri
0.027s PASS release32 std.stream
0.046s PASS release32 std.concurrency
0.015s PASS release32 std.bitmanip
0.123s PASS release32 std.array
0.055s PASS release32 std.bigint
0.005s PASS release32 std.base64
0.350s PASS release32 std.zlib
18.893s PASS release32 std.parallelism
0.005s PASS release32 std.json
0.009s PASS release32 std.numeric
0.372s PASS release32 std.file
0.080s PASS release32 std.algorithm.searching
0.007s PASS release32 std.algorithm.setops
0.085s PASS release32 std.algorithm.mutation
0.065s PASS release32 std.algorithm.sorting
0.010s PASS release32 std.algorithm.comparison
0.013s PASS release32 std.algorithm.iteration
0.000s PASS release32 std.container
0.010s PASS release32 std.container.util
0.000s PASS release32 std.container.binaryheap
0.113s PASS release32 std.container.rbtree
0.003s PASS release32 std.container.array
0.001s PASS release32 std.container.slist
0.001s PASS release32 std.container.dlist
0.510s PASS release32 std.digest.md
0.121s PASS release32 std.digest.crc
0.640s PASS release32 std.digest.ripemd
8.470s PASS release32 std.digest.sha
1.285s PASS release32 std.digest.digest
0.000s PASS release32 std.experimental.logger.nulllogger
1.119s PASS release32 std.experimental.logger.core
0.004s PASS release32 std.experimental.logger.filelogger
0.003s PASS release32 std.experimental.logger.multilogger
0.007s PASS release32 std.net.curl
0.138s PASS release32 std.net.isemail
0.022s PASS release32 std.range
0.030s PASS release32 std.range.primitives
0.000s PASS release32 std.range.interfaces
0.035s PASS release32 std.regex
0.000s PASS release32 std.regex.internal.ir
0.000s PASS release32 std.regex.internal.backtracking
0.073s PASS release32 std.regex.internal.generator
0.020s PASS release32 std.regex.internal.parser
3.029s PASS release32 std.regex.internal.tests
0.006s PASS release32 std.regex.internal.kickstart
0.000s PASS release32 std.internal.cstring
0.000s PASS release32 std.internal.scopebuffer
0.002s PASS release32 std.internal.math.biguintcore
0.000s PASS release32 std.internal.math.biguintnoasm
0.000s PASS release32 std.internal.math.errorfunction
0.002s PASS release32 std.internal.math.gammafunction


January 05, 2016
On Tuesday, 5 January 2016 at 00:34:19 UTC, Laeeth Isharc wrote:
> Huawei Watch rooted with custom OS (since it seemed easiest way to run an executable via adb shell, and Terminal Emulator is not so usable on that size screen).
>
> [...]

Heh, I didn't think anyone would get it running on a wearable with Android Wear, good to see D runs fine on there too.  The epmap thing doesn't work on all Android devices- see previous output in this thread- and I think wifi is working because none of the other tests in std.socket assert.
January 05, 2016
On Tuesday, 5 January 2016 at 04:30:38 UTC, Joakim wrote:
> On Tuesday, 5 January 2016 at 00:34:19 UTC, Laeeth Isharc wrote:
>> Huawei Watch rooted with custom OS (since it seemed easiest way to run an executable via adb shell, and Terminal Emulator is not so usable on that size screen).
>>
>> [...]
>
> Heh, I didn't think anyone would get it running on a wearable with Android Wear, good to see D runs fine on there too.  The epmap thing doesn't work on all Android devices- see previous output in this thread- and I think wifi is working because none of the other tests in std.socket assert.

That's v interesting if true, as I had thought it was crippled.  (It might be the custom boot image that is the reason for this - I would have liked to have try on stock but was just too much trouble to figure out how to get the executable onto somewhere I could run it, and pretty hard to control terminal from the watch - not even an onscreen keyboard comes up).

One case where little D scripts might already be potentially usable - whether on tablet or wearable - would be to trigger them via Tasker (and its plugins/clones on Wear).
January 05, 2016
On Tuesday, 5 January 2016 at 04:30:38 UTC, Joakim wrote:
> On Tuesday, 5 January 2016 at 00:34:19 UTC, Laeeth Isharc wrote:
>> Huawei Watch rooted with custom OS (since it seemed easiest way to run an executable via adb shell, and Terminal Emulator is not so usable on that size screen).
>>
>> [...]
>
> Heh, I didn't think anyone would get it running on a wearable with Android Wear, good to see D runs fine on there too.  The epmap thing doesn't work on all Android devices- see previous output in this thread- and I think wifi is working because none of the other tests in std.socket assert.

drop me an email if you have time - laeeth at
kaleidicassociates.com
January 17, 2016
On Sunday, 1 November 2015 at 05:44:04 UTC, Joakim wrote:
> I've been running the druntime and phobos tests from the master 2.068 branch on various Android devices.  Please try out the Android test runners I just made available and report your own results in this thread:
>
> https://github.com/joakim-noah/android/releases/tag/runners
>
> Some output is expected and doesn't need to be reported, while any other deviations should be reported.  Please report the Android version, found in Settings->About Device->Android Version; the manufacturer; the chipset, which can be found on device databases like gsmarena; and which runners you ran.  If you google your device's name, usually the first link is the gsmarena entry.  For example, the Samsung Galaxy S6 uses the Exynos 7420:
>
> http://www.gsmarena.com/samsung_galaxy_s6-6849.php
>
> I'm using this ldc forum for this device reporting because it doesn't require any registration, unlike the wiki or github.  I'll collect all the results and put them on the wiki later.
>
> All source is available to build ldc and the test runner yourself, only missing the build script I used for the apk version of the test runner.  I'll write up the build process on the wiki and push that last script into CMake next.
>
> Expected output:
>
> - Bionic didn't support hex format for floating point, either for literals or output, until Android 5.0.  As a result, I skip such tests in std.conv and std.format if they fail.  The command-line test runner will note that those tests were skipped on pre-5.0 Android: that's expected and only needs to be reported if it _doesn't_ happen on pre-5.0 Android.

I've released updated test runners on github:

https://github.com/joakim-noah/android/releases/tag/polish

I count eight issues reported in this thread.  Here's the list, along with what has been or needs to be done:

1. std.stdio and std.socket hang on Android 5.0- this was because of a regression with locking stdout in bionic 5.0, hacked in a workaround so it shouldn't hit anymore.

2. rsw0x reported a failing test in std.file from the command-line runner on Android 6.0- others didn't have an issue with the apk on 6.0, not sure what to make of this one.

3. Nick and TheFlyingFiddle reported several modules asserting because of getcwd on Android 4.1- this was because calling getcwd with the arguments null and 0 was not supported before 4.2, put in a workaround so it shouldn't cause a problem.

4. Vlad reported an issue with one time zone in std.datetime- we narrowed it down to the timezone parser from bionic on his device not reading the timezone data properly, left the issue there as it doesn't hit anybody else.

5. Austin G reported several modules hanging on his G4- I need more info about this, since it's the only device with these problems.

6. Yazan D reported std.datetime asserting for his timezone- as he said, this is a problem upstream too, so not specific to Android.

7. Jakob reported two modules asserting when trying to create links in the Downloads directory- this is likely related to Android not allowing symbolic links on the /sdcard partition, as he said it works fine in the /data partition.

8. Jakob reported a segfault from the command-line test runner after all tests are run, related to the static destructor for std.parallelism interacting somehow with core.thread- I've seen this occasionally but not in a while, so put it aside for now.

So, 1 and 3 were worked around; I'll need more info on 2, 4, and 5; 6 and 7 are out of scope of this Android port; and 8 will need to be pinned down at some point, once it can be reproduced consistently.

Please try out the updated test runners, particularly if the previous ones asserted anywhere for you, and report your results in the same format as before.
January 18, 2016
Hi Joakim,

On 17 Jan 2016, at 12:24, Joakim via digitalmars-d-ldc wrote:
> I've released updated test runners on github:
>
> https://github.com/joakim-noah/android/releases/tag/polish

I don't have much to contribute right now but thank you for keeping us updated on the progress. We should probably figure out how to go forward with integrating this into mainline LDC soon (how do the upstream LLVM TLS support additions affect this, by the way?).

I'm bringing this up now because the upcoming 2.069 merge (with the move to the D frontend) has the potential to be quite disruptive to long-term projects like yours, and I want to be sure things do no grind to a halt because of that.

Best,
David
January 18, 2016
On Monday, 18 January 2016 at 09:32:06 UTC, David Nadlinger wrote:
> Hi Joakim,
>
> On 17 Jan 2016, at 12:24, Joakim via digitalmars-d-ldc wrote:
>> I've released updated test runners on github:
>>
>> https://github.com/joakim-noah/android/releases/tag/polish
>
> I don't have much to contribute right now but thank you for keeping us updated on the progress. We should probably figure out how to go forward with integrating this into mainline LDC soon (how do the upstream LLVM TLS support additions affect this, by the way?).

Yes, I wanted to polish off some of these remaining rough edges before submitting PRs.  I will do that next, as there's only a couple failing tests left and they don't bother me.

As for "the upstream LLVM TLS support additions," I assume you're talking about the recent support for emulated TLS added to llvm 3.8, that mimics the way gcc does it.  I tried it out a while back, works fine, except I'll need to figure out how to register that TLS data with the GC, as Johannes had to do for gcc.  I haven't looked into that last GC portion yet.

> I'm bringing this up now because the upcoming 2.069 merge (with the move to the D frontend) has the potential to be quite disruptive to long-term projects like yours, and I want to be sure things do no grind to a halt because of that.

Why do you say that: do you expect it to take a while to get the 2.069 release of ldc done?  Since I'm providing ldc as a cross-compiler, I don't see how it would affect the linux/x86 or linux/x64 host compiler.  It might affect the native Android/ARM host compiler, but I'm optimistic that that won't take much.

If you simply mean that merging might take a while after switching the ldc frontend to D, as my patches are against the current C++ version of ldc, my patches to the ldc compiler itself are fairly minimal. The vast majority is Kai's longdouble2 branch, which is only necessary when cross-compiling, and I suspect we could translate it fairly quickly if needed.

Long answer short: I don't expect the 2.069 merge to affect the Android port much, but I'll try to get some PRs in before then anyway.
January 18, 2016
Joakim <dlang@joakim.fea.st> writes:
>
>> I'm bringing this up now because the upcoming 2.069 merge (with the move to the D frontend) has the potential to be quite disruptive to long-term projects like yours, and I want to be sure things do no grind to a halt because of that.
>
> Why do you say that: do you expect it to take a while to get the 2.069 release of ldc done?  Since I'm providing ldc as a cross-compiler, I don't see how it would affect the linux/x86 or linux/x64 host compiler.  It might affect the native Android/ARM host compiler, but I'm optimistic that that won't take much.
>
> If you simply mean that merging might take a while after switching the ldc frontend to D, as my patches are against the current C++ version of ldc, my patches to the ldc compiler itself are fairly minimal. The vast majority is Kai's longdouble2 branch, which is only necessary when cross-compiling, and I suspect we could translate it fairly quickly if needed.

I think David did mean that your Android changes might get messed up by the update to D frontend 2.069.  I agree that Kai's longdouble2 branch could be the most work, but it is pretty straight forward and might be easier to just reimplement as LDC starts using 2.069 D frontend.
-- 
Dan
January 19, 2016
On Sunday, 1 November 2015 at 05:44:04 UTC, Joakim wrote:
> I've been running the druntime and phobos tests from the master 2.068 branch on various Android devices.  Please try out the Android test runners I just made available and report your own results in this thread:
>
> [...]

Android 5.1, Motorola, Snapdragon 410: all tests pass using the APK.
April 21, 2016
On Sunday, 17 January 2016 at 11:24:58 UTC, Joakim wrote:
>
> I've released updated test runners on github:
>
> https://github.com/joakim-noah/android/releases/tag/polish
...
> 3. Nick and TheFlyingFiddle reported several modules asserting because of getcwd on Android 4.1- this was because calling getcwd with the arguments null and 0 was not supported before 4.2, put in a workaround so it shouldn't cause a problem.
>

I retested. All tests now pass

Android: v4.1.2
Device: SCH-I535 (Samsung Galaxy S3 Verizon)
Chipset: Snapdragon S4 Plus
Rooted: Yes
Custom ROM: No

0.581s PASS core.time
0.005s PASS core.memory
0.035s PASS core.bitop
0.260s PASS core.thread
0.000s PASS core.math
0.000s PASS core.checkedint
0.000s PASS core.atomic
0.000s PASS core.exception
0.020s PASS core.demangle
0.000s PASS core.internal.convert
0.000s PASS core.internal.hash
0.016s PASS core.sync.rwmutex
0.034s PASS core.sync.condition
0.008s PASS core.sync.mutex
0.000s PASS core.sync.config
0.007s PASS core.sync.barrier
0.000s PASS core.sys.posix.sys.select
0.000s PASS core.sys.linux.tipc
0.000s PASS ldc.eh.fixedpool
0.007s PASS object
0.000s PASS rt.aApplyR
0.000s PASS rt.minfo
0.004s PASS rt.arraydouble
0.000s PASS rt.monitor_
0.000s PASS rt.arraycast
0.000s PASS rt.aApply
0.000s PASS rt.arraybyte
0.001s PASS rt.arrayshort
0.021s PASS rt.arrayint
0.000s PASS rt.arrayassign
0.000s PASS rt.typeinfo.ti_Aint
0.000s PASS rt.aaA
0.000s PASS rt.arrayreal
0.001s PASS rt.arrayfloat
0.000s PASS rt.cover
0.018s PASS rt.lifetime
0.000s PASS rt.util.string
0.000s PASS rt.util.typeinfo
0.261s PASS rt.util.container.treap
0.000s PASS rt.util.container.hashtab
0.000s PASS rt.util.container.array
0.000s PASS rt.util.utf
0.000s PASS rt.util.hash
0.000s PASS rt.switch_
0.006s PASS rt.adi
0.000s PASS rt.qsort
0.000s PASS gc.config
0.000s PASS gc.bits
0.000s PASS gc.pooltable
0.000s PASS gc.gc
0.071s PASS std.uuid
0.000s PASS std.outbuffer
0.009s PASS std.numeric
0.012s PASS std.traits
0.019s PASS std.encoding
0.042s PASS std.format
0.163s PASS std.string
5.982s PASS std.socket
0.114s PASS std.file
0.007s PASS std.xml
2.110s PASS std.process
1.182s PASS std.uri
0.004s PASS std.functional
0.077s PASS std.stream
0.004s PASS std.json
0.013s PASS std.csv
0.006s PASS std.getopt
0.106s PASS std.conv
0.003s PASS std.ascii
0.290s PASS std.stdio
0.676s PASS std.uni
0.000s PASS std.typetuple
0.010s PASS std.bitmanip
0.113s PASS std.zlib
0.000s PASS std.typelist
0.000s PASS std.signals
0.026s PASS std.utf
0.000s PASS std.mathspecial
15.397s PASS std.datetime
0.031s PASS std.path
0.001s PASS std.cstream
0.002s PASS std.meta
0.021s PASS std.bigint
0.059s PASS std.variant
0.004s PASS std.math
0.016s PASS std.typecons
6.746s PASS std.parallelism
0.002s PASS std.base64
0.001s PASS std.mmfile
0.029s PASS std.zip
0.062s PASS std.array
33.843s PASS std.random
0.002s PASS std.complex
0.018s PASS std.exception
0.014s PASS std.concurrency
0.002s PASS std.algorithm.comparison
0.041s PASS std.algorithm.iteration
0.006s PASS std.algorithm.mutation
0.076s PASS std.algorithm.searching
0.030s PASS std.algorithm.sorting
0.013s PASS std.algorithm.setops
0.000s PASS std.container.binaryheap
0.000s PASS std.container
0.000s PASS std.container.slist
0.007s PASS std.container.util
0.000s PASS std.container.dlist
0.111s PASS std.container.rbtree
0.024s PASS std.container.array
0.162s PASS std.digest.md
0.196s PASS std.digest.ripemd
0.053s PASS std.digest.crc
0.270s PASS std.digest.digest
3.978s PASS std.digest.sha
0.720s PASS std.experimental.logger.core
0.001s PASS std.experimental.logger.multilogger
0.000s PASS std.experimental.logger.nulllogger
0.001s PASS std.experimental.logger.filelogger
0.022s PASS std.net.curl
0.095s PASS std.net.isemail
0.035s PASS std.range
0.000s PASS std.range.interfaces
0.020s PASS std.range.primitives
0.071s PASS std.regex
0.003s PASS std.regex.internal.kickstart
0.023s PASS std.regex.internal.generator
0.000s PASS std.regex.internal.backtracking
0.005s PASS std.regex.internal.parser
1.041s PASS std.regex.internal.tests
0.000s PASS std.regex.internal.ir
0.000s PASS std.internal.scopebuffer
0.000s PASS std.internal.math.errorfunction
0.001s PASS std.internal.math.biguintcore
0.006s PASS std.internal.math.gammafunction
0.000s PASS std.internal.math.biguintnoasm
0.000s PASS std.internal.cstring